Support manually passing page_view_id

[colmsnowplow]

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_creation event must be sent from the server-side, it could share a page_view_id with a submit_form event on the client-side).

[alexanderdean]

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?

[colmsnowplow]

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.

[alexanderdean]

I think we are against manual overrides.

[colmsnowplow]

Hey @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.

[alexanderdean]

Oh sorry, we misread it. Please move over!

[mscwilson]

This can be implemented as an optional Page object to attach to any tracking calls, as in the Ruby tracker.