feat: [UIE-9805] - Extract EUUID from /profile header and send to Adobe analytics #13229
Conversation
jdamore-linode
left a comment
jdamore-linode
left a comment
There was a problem hiding this comment.
Hey @tanushree-akamai, having trouble finding a way to test this, but will continue looking into it tomorrow. Feel free to reach out if you have any questions/suggestions! Thanks!
@jdamore-linode : I have elaborated on the testing steps, hope it helps! |
pmakode-akamai
changed the title
|
|
||
| import { ADOBE_ANALYTICS_URL } from 'src/constants'; | ||
| import { reportException } from 'src/exceptionReporting'; | ||
| import { getStoredCustomerUuid } from 'src/utilities/analytics/utils'; |
There was a problem hiding this comment.
| import { getStoredCustomerUuid } from 'src/utilities/analytics/utils'; | |
| import { getStoredCustomerUUID } from 'src/utilities/analytics/utils'; |
I think we should use `getStoredCustomerUUID (or getStoredCustomerEuuid, whichever is appropriate) and update all references in this PR for consistency
| * Flag to ensure we only send the EUUID to Adobe Analytics once per session. | ||
| * The EUUID doesn't change during a session, so we only need to track it once. | ||
| */ | ||
| let hasTrackedCustomerUuid = false; |
There was a problem hiding this comment.
I'm NOT too sure, but I wanted to point out that this flag looks to be module-scoped, not session-scoped, so it will reset on page reload (i.e. once per JS runtime load). This could potentially lead to duplicate analytics events
The comment mentions "once per session", but it's unclear to me what 'session' means in this context.
Given that we already store the EUUID itself in module-level state (storedCustomerUuid) for later analytics usage, this seems more aligned with an authenticated session rather than a browser session -- but the current implementation doesn't explicitly tie this to auth boundaries
Is "session" here intended to mean:
- an authenticated session (login -> logout / token expiration) OR
- a browser session (tab/window lifetime)?
Depending on the intent we may want to:
- reset this on auth/token changes OR
- persist it via sessionStorage rather than keeping it in memory
Could you clarify the intended semantics here?
tanushree-akamai
force-pushed
the
feature/UIE-9805-euuid-for-adobe-analytics
branch
from
2ac8885 to
04cab1b
Compare
tanushree-akamai
force-pushed
the
feature/UIE-9805-euuid-for-adobe-analytics
branch
from
04cab1b to
ce9cfa2
Compare
…terceptor level and share it with Adobe analytics through the page view event
Cloud Manager UI test results🔺 1 failing test on test run #6 ↗︎
Details
TroubleshootingUse this command to re-run the failing tests: pnpm cy:run -s "cypress/e2e/core/linodes/clone-linode.spec.ts" |
|||||||||||||||||
jdamore-linode
left a comment
jdamore-linode
left a comment
There was a problem hiding this comment.
Thanks @tanushree-akamai! I believe I was able to verify this locally, but I'll be sure to take a second look in Staging/Prod when the time comes as well just to be sure.
4 participants
Description 📝
Make the EUUID (Enterprise UUID) from the X-Customer-Uuid API response header available to Adobe Analytics via _satellite.track(), including for users with restricted billing access.
Changes 🔄
List any change(s) relevant to the reviewer.
Scope 🚢
Upon production release, changes in this PR will be visible to:
Preview 📷
How to test 🧪
Verification steps
_satellite.setDebug(true)Author Checklists
As an Author, to speed up the review process, I considered 🤔
👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support
As an Author, before moving this PR from Draft to Open, I confirmed ✅