We’ve got an audio training app, and would need to assess which audio sessions are mostly being consumed by users, and which are not. I cannot find the data in Adalo or Mixpanel analytics. As it’s a pretty basic requirement, I assume the data is there but I just can’t find it. Any ideas?
I feel the whole analytics side is a big letdown as it currently is.
Hi @Mikko ,
I have read somewhere that mixpanel only track the screens regardless the data passed through inside it.
So in your use case, it might need additional collection as a log, every time users go to that session, do action create to this log.
Hi Yongki, thanks for the very useful insight!
It’s a big ask, but would you be able to help me with the specifics (I’m fairly new to Adolo, with a non-technical background), and not sure how to make this happen…
I need to look at the database setup first, all our logic depends on it.
Ok, would you like to? Is there a way?
Take multiple screenshots inside the collection.
You can create additional collection called Listened Exercises and the fields are
1 basic field, 4 relationship fields
At Exercises collection, you can add numbers field called counter, this is where we add +1
At Trainer collection, you can add numbers field called counter, this is where we add +1 (same logic)
At Sports collection, you can add numbers field called counter, this is where we add +1 (same logic)
Now for the logic on screen,
Whenever user play the audio session, add action to create this new collection, Listened Exercises and fill the relevant information with current available data.
Add another action to update +1 at Exercises collection, with syntax current exercises>counter+1 (this will hold life time value of this exercise is played by users)
Add another action to update +1 at Trainer collection, with syntax current exercises.trainer>counter+1 (this will hold life time value of all exercises by this trainer is played by users)
Add another action to update +1 at Sports collection, with syntax current exercises.sports>counter+1 (this will hold life time value of all exercises by this sport is played by users)
So, when we want to know which exercises are most listened, we can use count for this new collection, or as backup field, we have counter in the exercise collection that hold life time value of how many user visit this exercise, but if we want to go deeper who are the users, we should use count in the listened exercise collection.
The same logic goes for trainers and sports, they have their own life time value that can work as subtotal of the new collection.
Oh wow, this is so helpful! Thank you so much, takes me a while to decode but should be able to implement. I’m very grateful, @Yongki!
I’ve implemented this without any problems according to your amazing instructions @Yongki
Mobile app usage doesn’t register though, only PWA that we don’t really have users on. Any idea what might cause this?
Thanks again!
Hi @Yongki Just wanted to check back to see whether you might know why anytime someone listens to a session, tens of records are added in the database, instead of 1?
So, instead of the counter adding +1, it adds anything between around 10 to 50, therefore any collection I look into, it appears there’s tens of times more usage than there is in reality.
Hi @Mikko ,
My first guess would be that you put action in the visit screen ?
If it is, try putting somewhere else.
Hi @yongki, not sure what you mean by the visit screen. All the actions are now attached to the audio player component, and I wouldn’t think they would work elsewhere as they are only related to playing audio… Maybe I’ve misundestood something?
Thanks again!
Hi @Mikko ,
Ohh, attached to that.
Another idea would be to implement boolean field, so there is an action to update this field as true first and then create the log with conditional of field=true, the update the boolean to false.
This will provide additional measure so the log can be create with the intended conditional, or you can experiment with number, if number <1, something like that.
Your original solution works 100% correct with the PWA, but with iOS and Android it creates tens of too many records, so I assume there’s a bug in the software somewhere.
Thank you for the new proposal. I don’t fully understand it, tbh, but I’ll try to get my head around it somehow.
