Allow certain params to be set via QS vars

[jrobgood]

Allow certain params such as UID / user_id to be consumed and set using the existing querystring parser functions, just like pushing a value via setUserId.

Use cases: clickthroughs from email campaigns, partner/affiliate sites with a shared key for known users, pseudo-session (obviously no PII or security assertion) handoff from one UA to another, e.g.: web (desktop) to mobile, mobile to media device, whatever.

Bonus points for opening up the entire SE and UE event types to this kind of flexibility.

Things to think about:

• Does this persist in the cookie, and if so, what happens when new values collide with previously-known values?
• Truncating the columns in the ETL job so nothing overflows (and errors out on the L part of ETL)
• Allow for this flexibility in the no-js collection method, which I assume is limited currently by rules in the enrichment process, unless any and all params are pushable into their columns so long as the right key/value pairs appear in the qs to the static gif.

[alexanderdean]

What about something like:

setUserIdFromReferer('oaid'); // Where 'oaid' is the name of a querystring name-value pair

See also:

• Explore whether we should add utm_x to Tracker Protocol snowplow#376
• Add namespace support for business user IDs #43

[jrobgood]

Seems sane, yes.

Question: could that value be persisted throughout the session, or would you need to write a procedure in the enrichment process to pick it up on point of entry, then backfill it into subsequent event rows with the same session id?

[yalisassoon]

Hi Robert Goodyear (@jrobgood) - we don't believe in persisting values in cookies.

Business user IDs are set whenever makes sense on a customer journey. (A good example is when a user logs in to a website, for example.) When the setUserId method is fired, an event is created in the Snowplow events table where the Snowplow cookie IDs (domain_userid and network_userid) can be matched to the business user_id field.

You can then create a mapping table e.g. of domain_userid to business user_id:

CREATE VIEW user_id_to_domain_map AS
SELECT
user_id,
domain_userid
FROM atomic.events
WHERE user_id IS NOT NULL
GROUP BY 1,2;

and then join that view with the events table to effectively "backfill" that user ID across every event that occured for that user before / after the actual setUserId method was called e.g. to pull the complete event stream for user ID = 'customer@domain.com'

SELECT *
FROM atomic.events e
JOIN user_id_to_domain_map m
ON m.domain_userid = e.domain_userid
WHERE m.user_id = 'customer@domain.com'
ORDER BY collector_tstamp

We like this approach because it is flexible, makes it easy to "backfill" user IDs across previous records where a user took action, but before e.g. they logged in, and avoids us having to reason who the user is at data collection time. (Delaying that reasoning so it happens at analysis time.)

Does that sound like a sensible approach, from your perspective?

[jrobgood]

Makes sense. So yeah, if the customer journey could begin via QS var, that'd be quite awesome.

You guys have any opinions on bullet point #3 of my original post?

[alexanderdean]

Allow for this flexibility in the no-js collection method, which I assume is limited currently by rules in the enrichment > process, unless any and all params are pushable into their columns so long as the right key/value pairs appear in > the qs to the static gif.

The no-js collection method is essentially just the raw form of the Tracker Protocol - you can put anything you like on the QS to the static gif, as long as it conforms to the Snowplow Tracker Protocol. So in this case, you can manually construct a QS containing ...&uid=user123&...

Does that answer your question? See also:

• Scala Common Enrich: add JavaScript scripting enrichment snowplow#378

[jrobgood]

I'm finding that my attempts to write events in the no-js manner are unreliable. Not sure if they're falling out in the ETL process or elsewhere. I'll be back soon with some concrete examples.

[alexanderdean]

Thanks, keep us posted!
On Oct 24, 2013 7:51 PM, "jrobgood" notifications@github.com wrote:

I'm finding that my attempts to write events in the no-js manner are
unreliable. Not sure if they're falling out in the ETL process or
elsewhere. I'll be back soon with some concrete examples.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-27019545
.

[jrobgood]

I'd like to send you some log rows and DB rows offlist. Let me know if that's cool, and where I should send them.

[alexanderdean]

That's fine - x@y where x is alex and y is our website's domain.

[alexanderdean]

Created a child ticket ^^.

Keeping this ticket open as some interesting possibilities open up once we have custom unstructured context (#49).

For example, we could let people programmatically generate specific named custom contexts.

[alexanderdean]

I don't think this one still needs to be in-scope for the tracker, closing