[Discussion] Add Tracking Header to SDK Requests

[msmollin]

Per various discussions started by @ecgreb it sounds like we can work on adding tracking headers to SDK requests that, once the backend is ready, can start to be added into redshift for reporting purposes later.

I propose a format that looks like:
x-mz-sdk: <platform>-<semver>-<release_status>

The <release_status> would be optional so as to distinguish between dev and prod versions of the SDK.

For in-development that would look like:
x-mz-mobile-sdk: ios-1.0.0-dev

For release builds we'd drop -dev and so we'd have:
x-mz-mobile-sdk: ios-1.0.0

Possible options for this optional field would be: -dev, -beta, -rc

This should be flexible enough to allow for a single unified header to represent any client platform hitting the backend service, with flexibility for their release schedules / types.

Thoughts? @bcamper / @rmarianski / @cedric / @sleepylemur / @sarahlensing

Once we land on something I'll open a similar ticket in the android sdk repo with final thoughts on implementation and reference there for discussion history.

[rmarianski]

I mentioned this on a tiles call today, and the question brought up was if we could just use the user agent header for this?

[msmollin]

Yep we can override that without issue if that's what we want.

[sleepylemur]

My memory is fuzzy, but I recall @cedric not liking the user agent override. Also I remember the reason user agent was being discussed was that there were some issues with browsers setting arbitrary headers (mapzen.js etc).

Adding analytics header parsing for all services will require updates to apiaxle-proxy, api-traffic-processors, schema updates to redshift, and rollup and query updates in analytics_api. Which is to say I don't have time to do it until after the metered platform push has settled down.

A shorter term solution of just adding header tracking to fastly for vector-tiles and/or pelias would be much simpler. I'll let the tiles team speak to whether that's something they have time to implement.

[rmarianski]

Also I remember the reason user agent was being discussed was that there were some issues with browsers setting arbitrary headers (mapzen.js etc).

Custom headers have their own complications with cors though.

A shorter term solution of just adding header tracking to fastly for vector-tiles and/or pelias would be much simpler. I'll let the tiles team speak to whether that's something they have time to implement.

This is what I was thinking.

[msmollin]

Is there a reason we can't have custom headers for mobile and user agent tracking for JS?

[rmarianski]

Is there a reason we can't have custom headers for mobile and user agent tracking for JS?

Not really, just nicer if it's the same.

We discussed this a little bit more on the tiles side, and having a separate analytics service that mapzen.js and the sdks talk to in order to pass in stats might be something to consider as well.

[iandees]

a separate analytics service

Yep, I brought this up because I worry about trying too hard to work around HTTP limitations, client differences (mobile clients vs. browser), and coming up with a solution for all SDKs. It makes a lot of sense for the SDKs to set User-Agent to a string that has our SDK version in it, but where that isn't possible it doesn't make sense to spend much time coming up with workarounds.

A bare minimum "tracker bug" service could be a tiny key on an S3 bucket that the SDKs make a request to. We'd enable HTTP logging in CloudFront or Fastly and throw the logs into RedShift for later querying like we do now. When Mapzen.js (or iOS or Android SDKs) starts up it could send a single request to this asset with query args like ?k=sdk.version&v=1.2.0. Then we could query that sort of thing in RedShift and figure out SDK usage rates. We could also have the SDK set a cookie so that we'd get that request once per user/session, too. We could record other actions or metadata, too, like screen size, scroll wheel capability, etc.

If we wanted to add even more useful information we could use a slightly smarter HTTP server that dumps all the request headers to RedShift, too.

[msmollin]

I concur with having a separate service in the long run as that makes the most flexible sense. Do you think it makes sense to start setting the User-Agent header now for the SDKs and start tracking that, and then migrate over once we have the separate service ready?

[iandees]

Yep, adding Mapzen stuff to User-Agent makes sense and will automatically get logged with our current system.

[iandees]

One thing that @zerebubuth pointed out was that if a device already has tiles cached we won't get any information from them in our logs. When we switch over to a metrics service we'll have to keep that in mind because the numbers will be different.

[msmollin]

Makes sense. One is tracking "total requests" and one would be like "active users/devices" so I would almost think they'd live together, not replace one with the other.