Third-party frontend integrations
Purpose: Add analytics, tag managers, consent, chat and A/B tools without wrecking performance, privacy or stability.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Frontend engineers | Owners of the page |
| Tech leads | Governance of what gets added |
The governance problem
Third-party scripts arrive via marketing ("just add this tag") and accumulate. Each one is arbitrary code executing on your users with your origin's privileges. Treat additions as changes requiring review, with an owner and a removal date where applicable.
Integration mechanics in AEM
| Need | Mechanism |
|---|---|
| Site-wide scripts (analytics, tag manager) | Page component customheaderlibs/customfooterlibs HTL, config-driven (page property or context-aware config for the ID) — NOT hardcoded |
| Per-environment IDs | Context-aware config / OSGi config per run mode (prod ID never fires on stage) |
| Consent gating | Consent manager loads first; other tags load only per consent state |
| Component-scoped widget (chat) | The component's clientlib, lazily |
Performance rules
- Everything third-party:
async/defer, never render-blocking in head (consent manager excepted by necessity, kept tiny). - Self-audit quarterly with a waterfall: each tag's cost, and whether anyone still uses its data.
- Tag-manager discipline: marketing-added tags still go through a review workflow; "the tag manager did it" is the classic unexplained-regression source.
- Set a performance budget for third-party JS (performance guidelines) and enforce in CI where possible.
Privacy & security rules
- Consent before any tracking fires (regional rules differ — consent platform owns the logic; your job is correct load order).
- No PII into analytics dataLayers — plan names fine; member numbers never (PII handling).
- Subresource Integrity for static third-party scripts where the vendor supports it; pin versions rather than "latest".
- CSP that allows exactly your vendor list and nothing more (TLS & headers).