Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TF-633] Feature: migrate to @segment/analytics-next package #1

Merged
merged 16 commits into from
Apr 15, 2022

Conversation

riffbyte
Copy link
Contributor

@riffbyte riffbyte commented Apr 11, 2022

  • Replaced the legacy analytics.js bundle fetched from our infrastructure with vanilla @segment/analytics-next package
  • Custom cookie domain is now a config entry for analytics-next, so no need to patch the code
  • Prezly Meta injection and sending events to analytics.prezly.com is implemented through the new Plugin feature of analytics-next
  • Analytics bundle is not loaded at all until the consent is given
  • If no Segment Write Key is set for the newsroom, the library is loaded without Segment.io integration, meaning that no requests are made to Segment API at all, only to analytics.prezly.com

Bonus:

  • Fix page event not being fired on initial page load (introduced in the initial implementation of the package)

@riffbyte riffbyte self-assigned this Apr 11, 2022
@@ -27,8 +23,11 @@ interface Props {
isEnabled?: boolean;
newsroom: Newsroom;
story: Story | undefined;
plugins?: Plugin[];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it would be a nice feature to allow the package consumers to pass their own plugins, that way they would be able to extend the features without the need to fork the library.

Comment on lines 12 to 13
const { analytics, consent, isEnabled, newsroom, trackingPolicy } = useAnalyticsContext();
const analyticsRef = useLatest(analytics);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of the changes to this file were basically about replacing window.analytics with the analytics object received from analytics-next.

Comment on lines +21 to +22
// TODO: Prezly Analytics app should be able to take the newsroom UUID from the `prezly` property
writeKey: newsroomUuid,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that in the legacy analytics bundle Newsroom UUID is passed twice: in the prezly property, and in the writeKey. This seems redundant, but analytics.prezly.com/track endpoints are giving 422 error when writeKey is not present.
I believe this can also be populated with the actual Segment write key, if the integration is enabled for the newsroom, and in that case the event gets passed along to Segment, but this will not be needed anymore with this package.

type: 'application/json',
});

navigator.sendBeacon(`${getApiUrl()}${endpoint}`, blob);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an alternative to fetch that was made specifically to send analytics data from the browser. The main advantage is that it isn't affected by the user closing the tab - the request would still be fulfilled in the background.
See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why we'd opt for sendBeacon and the native analytics-next is not. Is there a caveat?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's because it's not supported by IE11: https://caniuse.com/?search=sendbeacon
But since we ditched support for it a while ago, I don't see this as an issue.

@@ -1,213 +1,3 @@
// https://www.npmjs.com/package/@types/segment-analytics
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file used to include the types copied over from the Segment package, now they're not needed anymore.

@riffbyte riffbyte changed the title Feature: migrate to @segment/analytics-next package [TF-633] Feature: migrate to @segment/analytics-next package Apr 11, 2022
@linear
Copy link

linear bot commented Apr 11, 2022

TF-633 Refactor the extracted library to rely on `@segment/analytics-next`

See TF-492 for details on how analytics work on our legacy infrastructure.

Key points to keep in mind:

  • One of the main reasons we have the custom logic for Prezly analytics is the cookie domain.

    Need to research if this is a feature that is supported by analytics-next, otherwise will need to re-implement it via a plugin (if it is possible)

  • We need to take into account other analytics integrations available to users: CookiePro and Google Analytics.

  • We want to completely disable tracking if it's disabled in the newsroom settings (no network requests made to anything related to analytics)

  • We need to include the logic to identify campaign recipients coming from email links

Comment on lines +62 to +67
// If no Segment Write Key is provided, we initialize the library settings manually
...(!writeKey && {
cdnSettings: {
integrations: {},
},
}),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code allows the library to initialize without a working Segment Write Key (it is used to fetch the source configuration from Segment, which we don't need to Prezly-only tracking).
Somehow the tracking calls to Segment API still go through even without authorization. This is handled later in the code.

Comment on lines +80 to +84
// Disable calls to Segment API completely if no Write Key is provided
...(!writeKey && {
// eslint-disable-next-line @typescript-eslint/naming-convention
integrations: { 'Segment.io': false },
}),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After digging through analytics-next source code, I found out that the code sending events to Segment is also a plugin (!), that can be disabled. This was an undocumented feature, but it effectively disables any calls to Segment API, while all the other plugins (like sending events to Prezly) still work fine.

Copy link
Contributor

@kudlajz kudlajz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

Copy link
Member

@pestaa pestaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not in favor of using undocumented features (since there's now less guarantee it'll be around), but sounds like we have a special use case.

💯

@riffbyte riffbyte merged commit baf856f into main Apr 15, 2022
@riffbyte riffbyte deleted the feature/migrate-to-analytics-next branch April 15, 2022 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants