I’m seeking guidance on how to effectively manage cookies generated by the Snowplow Browser SDK, particularly domain_userid and domain_sessionid, so they can be reliably used by the Snowplow PHP SDK on the backend.
In my current setup, the frontend is built with Next.js, while the backend is handled by PHP (Symfony). All user interaction events—such as form submissions, link clicks, etc.—are directly sent to the backend, where the Snowplow PHP SDK processes them.
To improve session and user tracking, I’m planning to introduce the Snowplow Browser SDK on the frontend, specifically for handling cookie creation and management. My key challenge is to ensure that the domain_sessionid is properly maintained and remains active during user interactions. For example, when a user submits a form or clicks a link, the session must stay active, and the domain_sessionid should be updated to reflect that activity. This session ID will then need to be synchronized with the backend, where the Snowplow PHP SDK processes the events.
In summary, my goal is to use the Snowplow Browser SDK to manage cookies on the frontend while ensuring that the session remains active and accurately reflected when user interactions occur, enabling the session data to be correctly passed to the Snowplow PHP SDK on the backend.
Please let me know your thoughts and please share your past experiences.
Are the events (server side + client side) happening within a reasonably short time of each other (e.g., client side events within 30 mins of the last server side event)?
If so your domain_sessionid will persist for this period and you shouldn’t have to do anything extra.
If you do need to ‘extend’ the session for some reason from the backend the easiest thing to do would be to return a signal from your backend that signifies to keep the session alive, which then triggers a client side snowplow('updatePageActivity') which will mark the user as active.
Yeah, you usually don’t have to worry about this much. Letting the web tracker SDK manage the cookies is usually sufficient, and you just have to parse the _sp_id.* cookie and set the Subject fields with the corresponding values.
It doesn’t look documented but the Tracker instance has an updateSubject method for updating it on the fly if you’re re-using a single instance, so you can just build a new Subject from scratch whenever you handle the incoming request.
The other values in that cookie can be collected on the frontend in the client_session entity if you have that configured (this will be default in v4); so the data might look a bit weird because things like eventIndex obviously won’t increment to account for your server-side events; but this is usually acceptable in most cases so you don’t need to update the cookie or anything to account for new values (the platform being srv/v_tracker from your PHP events is usually enough to explain the additional events).
which then triggers a client side snowplow('updatePageActivity') which will mark the user as active.
This just marks them as active for the sake of page pings, as if the user scrolled or moved their mouse. So this should only be required if the user is sitting idle on the page for a long time waiting for the server response and you want to keep firing page pings. If they’re not idle or on doing stuff on other pages or something it won’t be required.