I would like to track views, likes and clicks of a post.
For example, on page load a user will see an item which will increase its views, if they like it then the like counter goes up and then if they click the post to open it then this too is recorded.
I am confident on how to count the number of likes but I’m not too sure on how to track the views and clicks of the post.
I plan to display this data on a dashboard so the post creator can see their post’s stats.
The posts are also displayed in a repeating group.
When counting likes, you may want a table for that in order to limit users from liking posts more than one time. You would setup an event that saves it using an only when condition that with do a search for likes for the current user count is 0.
The click event, you just have a button with 2 workflows - record the event then go to the relevant page.
Use the on page load event to record views. However, you are displaying them in a repeating group, which means you would be doing database updates on a number of records every time the page loads which may affect performance/use a lot of server resources.
Wouldn’t a ‘view’ and ‘click’ be the same? On Page load would assume someone clicked through to a detail page.
I do this in my app but I use a ‘user list’ for likes and views. Then I use the count of that list in the display. Of course, this is because all my users are logged in and I have other features where you can see what other things people like when they like the same post, or ‘thing’ as you.
I realized that a “like” functionality is actually quite complex and I am still wondering how other apps implement it in such a performing way. The reason why it is complex, is, that most tables where you perform likes on have no user-context. So for example, a list of general posts does not have user-information, if you have set up a proper database structure. So it will not be straight-forward to display the user-specific like information on the general table without performing look-ups into other tables (in the worst case for each item in a repeating group).
Actually you would need to save the User-ID + the liked Item-ID in a dedicated table which takes some time, especially if you use external services like Airtable. As a consequence, I would consider holding the “like” in a state so that it becomes immediately visible on the front-end, delegating the creation of database entries in your “like” table to a backend workflow and then updating on page-load the state with the database-entry. Don’t forget to make sure that no duplicate entries are performed.
And if you use external services like me you have the pain of timing all of that properly and also refreshing repeating groups without page load events.
