Instant Search: Add TrainTracks analytics

[jsnmoon]

Changes proposed in this Pull Request:

This adds TrainTracks analytics calls to Instant Search results.

Is this a new feature or does it add/remove features to an existing part of Jetpack?

Yes, it adds analytics calls for rendering and interacting with Instant Search results.

Testing instructions:

• Add define( "JETPACK_SEARCH_PROTOTYPE", true ); to your wp-config.php.
• Ensure that your site has the Jetpack Pro plan and Jetpack Search enabled.
• Add a Jetpack Search widget to the Search page sidebar.
• Open your devtools network inspector and select a checkbox labeled Preserve Log.
• Enter a query into the site's search widget.
• Filter for stats.wp requests in the network inspector and ensure that you see a request for stats.wp.com/w.js?60.
• Filter for t.gif requests in the network inspector and ensure that you see 10 calls for t.gif with _en param equaling jetpack_instant_search_traintracks_render.
• Click on a search result link.
• Ensure that you see one additional call for t.gif with _en param equaling jetpack_instant_search_traintracks_interact.

Proposed changelog entry for your changes:

None.

[gibrown]

The jetpack_instant_search_traintracks_render events seem to have anon ids and the jetpack_instant_search_traintracks_interact events are picking up my wp.com id. I can't actually think of a reason why we need real ids associated with these events. I'm not even sure we need to fully persist the anon ids across page loads in a cookie but I think doing so would be good at the moment. But I don't want to do it if it means tracking folks across different sites.

I think we should remove all the parts that try to grab real user ids and entirely use anon ids since this is going to be fully on the front end of the sites. @xyu and @bperson can probably help point the way for this.

[bperson]

I can't actually think of a reason why we need real ids associated with these events. I'm not even sure we need to fully persist the anon ids across page loads in a cookie but I think doing so would be good at the moment. But I don't want to do it if it means tracking folks across different sites.

Considering we are analysing visitors of jetpack sites ( and not just owners of jetpack sites ), we should be extremely careful as this is new territory for Tracks in Jetpack AFAIK.

Did we ever do "search sessions" analysis? By that I mean not only tweaking the search algorithms to improve the results for a specific search query, but tweaking the results so that the user gets what he searches for without having to re-tweak its search query to be more specific.

If we don't think of doing analysis across different search queries, I don't think there is any value in using a persisting ID, which means we MUST NOT do it: generate a random ID, store it in a variable or a global that will get discarded if the user leaves or reloads the page.

If we hope to do those analysis in a far fetch future, we should also NOT DO it and only persist those IDs once we are sure we'll actually use that data.

[gibrown]

Did we ever do "search sessions" analysis?

I want to do this yes. But... a session could also be considered just all the interactions on the front end up until the page gets reloaded. So if we generate a single id each time the search app gets loaded, then that should be sufficient to at least start doing some session analysis.

The only case I can think of where storing something may be good is for A/B testing and wanting to make sure we provide the end user with the same side of the A/B test after they get it once. I'm not sure that matters a lot though.

So ya, let's not store anything in any cookies to start off with.

[jsnmoon]

@bperson @gibrown: I went ahead and removed parts of the code handling user identification. It now uses the default behavior from w.js.

User identification code removed.

[jsnmoon]

I believe I've addressed all outstanding concerns, so I'll go ahead and merge this PR in an hour or so.