Question

Integrate in backend, frontend, or both? (web-app)

  • 12 February 2019
  • 3 replies
  • 429 views

Userlevel 2
Badge
  • Frequent Contributor
  • 5 replies

I have a web application that I have been trialing Mixpanel on. Before I buy, I would like to clean up the integration to make sure we're using it in the best possible way.


Should we be tracking events and properties in the frontend, backend, or both?


Tracking in the frontend will allow us to easily capture user-interaction based events (i.e., clicked button, interacted with widget, etc.)


Tracking in the backend will allow us to easily track custom internal properties (i.e., duration of API call, internal database IDs, internal status codes).


What are the best practices here?



3 replies

Badge

Best would be both. But there are scenarios where that is not applicable.

Back-end tracking has the advantage to capture everything as it relies in your server logs. However, it costs a lot infrastructure and storage capacities and the information is rather one-dimensional. It is in some scenarios also harder to setup.

Front end tracking has the advantage of delivering much more user focused data such as browser, device and a lot behavioural stuff, as it sends signals from the user's browser to the analytics server. Furthermore, with tools like Mixpanel, it is comparable easy, fast and cheap to set up.

So, it depends on what you need. Do you need reliability (eg for billing, or for technical error tracking, transfers), then you need to work with backend data. Are you going for website optimisation or tracking front end errors, front end data would most often serve you better.

Hope this helps


Badge

Hey @amp!

To @jacob-j's point, the composition of your tracking between back-end and front-end will largely depend on:

  1. the current systems you have in place to enable back-end tracking (what is the cost to set-up and maintain back-end tracking?)
  2. the nature of your business and the origin source of the data you're interested in analysing (what is the most representative, reliable source of tracking for the given piece of data you're looking to track?)

generally speaking, the most comprehensive, robust implementation are hybrid implementations that involve a combination of server and client side tracking to maximise on the benefits of each tracking -

Server-side:

Reliability - in addition to technical error tracking, you can ensure that a "Payment: Submitted" event is more accurate if it's validated having gone through your back-end before being tracked through a server-side call VS sending it when a billing confirmation web page is loaded on your users' devices. You can also avoid discrepancies caused by overly aggressive ad-blockers installed on users' devices.

Client-side:

Mixpanel's client-side SDKs do maintain a persistent state for each user who visits your site, and will automatically a list of meta-data by default.

For Mixpanel's JS library, this storage layer users either the browser's localStorage or a browser Cookie, depending on how you've configured it.

Please reference this article to see the list of data that is tracked by default client-side. Additionally, aside from geo-location data (that is recorded and determined upon ingestion on our end, not locally on the device) and the 'last seen' property listed in the article, all data listed (including any super properties you register client-side using the mixpanel.register() method can actually be grabbed locally by parsing out the mixpanel cookie (mixpanel.cookie), or using the mixpanel.get_property() method.

The implications here is that from a developer's perspective, it can be easier to manage and iterate upon your implementation set-up.

Lastly, we've seen teams grab locally stored data by parsing out the cookie/using the mixpanel.get_property() method before passing it along to their back-end before finally sending in all related data through server-side - this is one example of how customers combine the benefits of server and client-side tracking.


Userlevel 2
Badge

Thanks Jacob and Arthur!

Few follow-up questions about Super Properties with respect to keeping things in-sync.


Q1) Are Super Properties stored on a per-event basis? or per-user?

Q2) If we earlier did {"age": 29} as a Super Property on a user and then later do {"age": 30}, what happens? Does this update all past instances of 'age: 29'? Do all subsequent events get 'age: 30' until we manually change it again?

Q3) In a hybrid setup (web frontend + server-side), imagine the scenario of an e-commerce website.

A user goes to the payment page and fills out their credit card info. We do "Track: Payment Button Clicked" on the frontend.

In the backend, we process the payment and do "Super Property: paid=true".

Will the frontend automatically get this change and start doing `paid=true` for all subsequent events as well?


Reply