Analytics integrations

Abrantes focuses on running experiments (assigning variants, rendering changes, and persisting the assignment). Reporting is usually better handled by the analytics tools you already use across your site: you get existing dashboards, funnels, segmentation, retention, attribution, and data governance without building a separate reporting system.

Integrating your experiment engine with your analytics stack lets you:

• Compare outcomes by variant using the same conversion events you already trust (signups, purchases, leads, etc.).
• Segment results by audience (device, geography, acquisition channel, logged-in status, etc.).
• Keep one source of truth for business events instead of duplicating event definitions.
• Combine quantitative and qualitative data (events + funnels + heatmaps/recordings).

When possible, integrate Abrantes with the analytics tools already used throughout your site:

• Reuse existing consent management and tag governance.
• Keep long-term reporting in one place (no split "experiment reports" vs "site reports").
• Make comparisons easier (experiment traffic vs non-experiment traffic, historical baselines, etc.).

Different analytics tools answer different questions; it is common to use more than one:

• Classic event tracking (quantitative): page views, clicks, form submits, purchases, signups. Examples: GA4, Mixpanel, Matomo (and GTM as the routing layer).
• Heatmaps (qualitative): where users click/scroll and what they ignore. Examples: Hotjar, Microsoft Clarity.
• Tagged session/video recording (qualitative): watch sessions for specific variants to understand why metrics change. Examples: Hotjar, Microsoft Clarity.

After your experiment runs, use a significance calculator to validate whether the observed lift is statistically meaningful.

We recommend the Abrantes calculator. It supports up to 3 variants, lets you share an experiment link, and is designed to work well on mobile devices.

Abrantes assigns a testId and a numeric variant to the user. Integrations typically send a value like MyTest-0 (control), MyTest-1, MyTest-2, and so on.

There are three common patterns (you can mix them):

1. Exposure event (event-scoped): send a single "experiment exposure" event when the user is assigned.
2. Custom dimension / event parameter: attach the experiment+variant value as a parameter on your business events.
3. User labeling (user-scoped): set a user property/trait once so subsequent events can be broken down by variant.

GTM-style dataLayer

The add2DL plugin pushes an object into dataLayer. Default keys:

• event: run_ab_test
• ab_test_data: {experiment}-{variant} (example: PricingTest-1)
• experiment_name: {experiment} (example: PricingTest)
• variant_name: {variantPrefix}{variant} (example: v1)

These keys are configurable via Abrantes.settings.dataLayer (see settings reference).

Custom integrations (abrantes:track)

Several plugins dispatch a browser event you can listen to if you need a custom bridge:

• DOM event name: abrantes:track
• event.detail includes testId, variant, and tool-specific metadata

This is useful if you want to forward the same "experiment exposure" to another analytics SDK (or to standardize naming) without modifying Abrantes core.

The examples in the folder examples cover adding tracking scripts and calling the relevant Abrantes plugin methods. The notes below focus on what to configure inside each analytics tool so you can analyze variants.