Repository navigation
Support manually passing page_view_id #264
Description
Activity
Do you mean the back-end generates the page view ID and renders it into the front-end for the client-side events, or something else?
As with the session ID discussion, I'm open to dispute on this, but what I had in mind was the other way around.
Page View ID generated client side -> Sent to server side -> setPageViewID method available for the relevant server-side events for that PageView.
To illustrate: Image a use case where you're a content-driven website, with a 'sign-up' box on every content page (or any website with a sign-up option on many/every page) . You might want to attribute the server side account creation event with the page view id for the page that led them to sign up.
I had it in this order because I'm picturing a typical implementation beginning with client-side tracking, then server-side being considered post-fact, for practical reasons.
There may be pitfalls in thinking of it this way that I'm not taking into account.
I think we are against manual overrides.
Hey Alexander Dean (@alexanderdean) I believe this would've been for the Java tracker, and wouldn't be a suggestion of manual override - rather a feature request which might improve integration between server-side and client-side tracking.
Same with this one: https://github.com/snowplow/snowplow/issues/3611#issuecomment-828582540
I'm ok with it remaining closed, but wanted to mention in case you'd prefer move them to snowplow-java-tracker with that clarification of context.
Oh sorry, we misread it. Please move over!
Reacted by colmsnowplowThis can be implemented as an optional Page object to attach to any tracking calls, as in the Ruby tracker.
In cases where server-side tracking complements a web-page based model, it would be useful to be able to pass the page_view_id to the Java tracker, by retrieving the value from the client-side and passing it to a native method.
While conceptually it might not make a huge amount of sense to set a web page context with Server-side events, it would be a nice way to model the data when mixing client- and server-side data (eg. where an
account_creationevent must be sent from the server-side, it could share a page_view_id with asubmit_formevent on the client-side).