Extend cross-domain linking with more user/session information

[igneel64]

Extending the cross-domain linking capability with a new parameter format adding the information of cross-navigation to a URLEncoded(B64(contents)) value which will be placed in the cross-domain linker param (_sp).

The tracker now accepts a useExtendedCrossDomainLinker parameter of type ExtendedCrossDomainLinkerOptions:

{
/* Enables the new `_sp` format using the cross_navigation information */
 useExtendedCrossDomainLinker: true
}

{
/* Enables the new `_sp` format using the cross_navigation information plus optional configuration for `ExtendedCrossDomainLinkerAttributes` . */
 useExtendedCrossDomainLinker: {
  userId?: boolean;
  sessionId?: boolean;
  sourceId?: boolean;
  sourcePlatform?: boolean;
  /**
   * Allow for the collection of the link text when a cross-domain link is clicked. Can also accept a callback for customizing information collection.
   */
  reason?: boolean | ((evt: Event) => string);
}
}

The default behaviour is not changed.

Notes:

• Added testing-library/dom allowing us to test DOM interactions on unit type of tests.

[bundlemon]

BundleMon

Files added (6)

Status	Path	Size	Limits
✅	libraries/browser-tracker-core/dist/index.mod ule.js	+26.24KB	26.5KB / +10%
✅	trackers/javascript-tracker/dist/sp.js	+24.94KB	25KB / +10%
✅	trackers/javascript-tracker/dist/sp.lite.js	+15.22KB	16KB / +10%
✅	trackers/browser-tracker/dist/index.umd.min.j s	+15.07KB	15.5KB / +10%
✅	libraries/tracker-core/dist/index.module.js	+13.35KB	15KB / +10%
✅	trackers/browser-tracker/dist/index.module.js	+3.51KB	5KB / +10%

Total files change +98.33KB 0%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history

[matus-tomlein]

In terms of the configuration of the feature, there are a couple of things on my mind:

1. Nit: Would "optional" be better than "extended" as a name for the extra properties? Extended feels a bit like enhanced ecommerce – what will we call the extended extended version? :D
2. I think it would make sense to make the optional properties configurable – I can imagine some people might not want to send the userId or appId in the links but want the sessionId.

My suggestion would be to make the configuration something like this:

{
    crossDomainLinkerOptionalProps: {
         userId: true,
         sessionId: true,
         sourceId: true,
         sourcePlatform: true,
         reason: true
    }
}

We could also let users enable all optional props as you do now:

{
    crossDomainLinkerOptionalProps: true
}

[igneel64]

About the choise of extended in the naming I was thinking that this in v3 will add the 'new' way (b64) with the additional properties.
In v4 the old one would be removed and we would only keep this one.

If though we decide to keep the same formatting (split with dots), optional will be a better naming.

[matus-tomlein]

Just one nitpick about the dots at the end of the string but otherwise LGTM

[greg-el]

Is timestamp required for this type? It looks like the timestamp value will always come from here

[igneel64]

This type is only used internally for the creation of the domain values. I moved it around a bit to make it more clear.