WSTEAMA-1412: Add Reverb dependency as the transpiled version

[alex-magana]

Resolves JIRA [WSTEAMA-1412]

Overall changes

Integrate the hosted version of Reverb into the page for tracking purposes.

https://mybbc-analytics.files.bbci.co.uk/reverb-client-js/reverb-3.9.2.js

Code changes

• Add the hosted version of Reverb to the page.
• Use Reverb for page view events and component page/click events.
• Enable service level migration from the current tracking logic.

Testing

1. List the steps used to test this PR.

Helpful Links

Add Links to useful resources related to this PR if applicable.

Coding Standards

Repository use guidelines

[karinathomasbbc]

Do we need the same logic as above (lines 480-481)?

[alex-magana]

Thanks for highlighting this Karina.
I reckon we should. Let me take a look at the existing logic
to confirm what informed this.

[alex-magana]

I've set this to false in both buildReverbAnalyticsModel and buildReverbPageSectionEventModel.
This is informed by the documentation here.
I've checked the beacons and confirmed that idclient is still reported in beacons
fired to ATI/Piano.

[karinathomasbbc]

When I was working on my personalisation project, I had set it to be !!hashedId - see #11353 (comment)

@gavinspence is this something we would like to put in place now, or shall we leave it for later?

[alex-magana]

Thanks for the context. I've responded in the thread in 11353 for continuity.

I'll hold off merging pending steer from @gavinspence.

[alex-magana]

From discussing with @gavinspence, we've concluded that we should retain
isSignedIn as false to:

• reflect the current logic/UX where audiences are "visitors" and not "users"
• ensure that the data stored by Piano reflects that audiences are not signed in. This
  ensures that when personalisation is introduced, the aggregated sign-in data won't
  include data from a time when we reported visitors as being signed in even though they were not.

While investigating this, we've established that Reverb doesn't use hashedId to track
visitors. This property is used for accounts/users contrary to our initial understanding.
From the Reverb code, it appears Reverb logic doesn't use the cookie, atuserid,
to persist visitor IDs. We're awaiting clarification on how to pass in the idclient value.
Based on these findings, we may not need the user object in the Reverb config after all.

In summation, since visitors are identified using the idclient value obtained from
atuserid (or the equivalent cookie in Reverb), I believe we should be able to correlate visitors and accounts if/when they are created since we'll begin to pass in the hashedId which we'll then be able to cross-reference against existing idclient UUIDs.

Please let me know if this position works for you @karinathomasbbc , in which case we can proceed
to merge the PR and fix forward the idclient configuration once we've heard from Reverb.
With this merged, we should then be able to enable Reverb on TEST for Pidgin and examine the
tracking beacons further for any needed improvements prior to going LIVE for the low impact trial.

For future reference:

https://support.piano.io/hc/en-us/articles/4468178673170-Concept-of-Visitors

[karinathomasbbc]

That's fine @alex-magana, thanks for the detailed response and for following up with Product.

[alex-magana]

Brill! I'll proceed to merge this.
Thanks Karina.

[amoore108]

Stellar work!