Skip to main content

What is a good way to track an event property that applies to nearly every single event, but is not semantically a ‘user’ property?

 

Imagine an application like Google Docs, where you’re creating text documents online. You might have events like ‘Inserted Image’, ‘Applied Heading’, ‘Performed Undo’, ‘Inserted List’, ‘Corrected Typo’, ‘Added Comment' and some 50-100 more. And for every one of them, you’d like to record document id (the long string in the url https://docs.google.com/document/d/<documentId>/edit). You probably also want to record things like user’s access level to the given document (owner/editor/commenter/reader) and whatnot.

 

In this scenario, should documentId/documentAccessLevel/etc be event properties or a user properties? On one hand, it seems far easier to declare those as user properties and set them once each time user opens a document.

ampli.identify(currentUserId, {
    documentId: 123,
    documentAccessLevel: 'OWNER',
});

As opposed to computing and adding those properties manually for every one of your 100 events.

On the other hand, it’s odd to describe documentId as a user property, since there’s nothing user-related about it. And I’m wondering if there are unexpected downsides to doing this, as it feels a little hacky.

AFAIK there’s currently no concept of a “global event property” so using your example scenario it sounds to me like your best solution may well be to implement the documentId user property (of course remembering to update the value should the user change document).

Dan.

Hi @Nikita R 

As Dan mentioned, there isn’t a notion of a global event property in Amplitude yet. Although there is provision on the Data planning front for property groups which you can explore.

The usual approach here would be to have documentId/documentAccessLevel as event properties since these identify your document entity when the user interacts.

As you said, documentId as a user property hardly makes any sense. Since a user might interact with 100s of docs across various access levels, you will have to constantly update these if set on user level, which isn’t ideal. So depending on which document the user interacted with last, the user property set at that time would define the user state.

 

Alternatively, if your core analysis and use case is related to understanding your document interactions keeping the document as the primary entity ( rather than the user ), you could explore account level reporting.

Reply


Terms & ConditionsCookie settings