Skip to main content

Hey, we're building an invoice approval solution. Users have multiple views like an inbox, an approval view, or an archive. Each view can contain multiple documents as todos: documents in your inbox, waiting for processing, open approvals, or all approved documents from the past in your archive.

We believe that the number of documents a user has in each view is important context to understand behavior. For example, if you only have two approvals, then you probably don't search. But if you have 100+ documents in your inbox, then you probably search a lot.

Our first idea was to attach these counts as properties to each page view event, but that would be too much load. So now we want to add a new event called dashboard_viewed that is being fired each time a user visits the dashboard, which also happens to be the first page visited after login.

How can I combine the properties of the dashboard_viewed event with other event data, like page views?

For example, I want to see how many searches (page_viewed event where the search property has any value) users do (probably a table visualisation) that have an open_approval_count < 10 (property of the dashboard_viewed event).

So the question is: is it possible to combine data from two different events, one for pre-filtering, the other one for getting the data?

Hi @lars. I’m not aware of any property sharing mechanic across events...but there’s a workaround that I think should work for you.

You could use a Funnel chart. In the first step select your page_viewed event with a filter on search has any value. In the second step select your dashboard_viewed event with open_approval_count < 10 filter. Then in the “Measured As” section of the Funnel config, choose “Counting by Totals” and apply a short duration in the “Completed within” part (i.e. ensure the two events occur within X seconds of each other). In the resulting chart you’ll see the event counts in the table beneath the funnel which I think should give you what you need (or super close albeit not technically perfect!).


The only other thing I can think of is to have those event properties you mention also set as user properties, that way the “search” property value will persist into the dashboard_viewed. But I really wouldn’t advocate this as good practice, it’s merely another hack!


@dangrainger thanks. Lets back up for a second. Maybe our proposed way of solving that problem isn’t the best one. Any other idea how we could include that context when analysing?


Your first idea…I assume your intention was to have 1 event property per count type passed with the page view event? So say you had 50 different types of count value to grab, that would be 50 event props?

You could use an object array here instead, for example “documents”, and in that array have “type” and “count” elements. Then you’re only using 1 event property for the array, and two more assuming you then split out type and count. Then the 50 different count types instead just become 50 items in the object array. So in the first item you might set documents.type = “open_approvals” and documents.count = 10.

FYI it used to be that object arrays were only available to Growth/ Enterprise plans. I don’t know if that’s still a restriction.

Hope that makes sense, some more info in these pages:

https://amplitude.com/docs/analytics/charts/cart-analysis
 

 


@dangrainger we are only talking about three counts: inbox, approval, archive, maybe payments.

The concern was more that we would need to send the counts every time a page is viewed, if we include it to every page view event. This would be a lot of load to the system. So more a performance concern.

i guess another option would be to introduce a dedicated search event since we’re especially interested in that context data in the context of search. 


OK here’s how we solved it: we’re sending the document counts as user properties every time the user visits the inbox, approval view, or archive. I learned that when we combine the user properties with an event, Amplitude will match the historical value of the user property the user had when the event got fired. Pretty neat!


Reply