Migrating from Adobe Analytics to Mixpanel: Extended

Guide

Key Differences: Mixpanel vs. Adobe Analytics

• Mixpanel → Event-based (schema-on-read)
• Adobe Analytics → Schema-based (schema-on-write)
Tracking model
• Mixpanel: User actions = events (e.g., “Page View”, “Purchase”), with properties (e.g., “Page
URL”, “Product Name”).
• Adobe: User actions = hits. Requires pre-configured variables (eVars, props, etc.).
User Identification
• Mixpanel: $device_id + .identify(user_id)
• Adobe: Multiple IDs (post_visid_high/low, vid, etc.), less transparent.
Metric Differences
Metric Adobe Analytics Mixpanel

Visits Sessions reset after 30 mins / 12 hrs Continuous by default

Page Views Counted per visit Counted as events

Visitors Browser/device-dependent IDs Clean user profiles via IDs

Getting Started with Mixpanel

• Use SDKs to send events.
• Auto-track page views + UTMs:

mixpanel.init('YOUR_TOKEN', { track_pageview: true });

• Example:

mixpanel.track("Played song", { "genre": "hip-hop" });

• Use Marketing KPI templates for dashboards.

Integration Options
1. CDPs (Segment, mParticle, Rudderstack) → reuse existing events.
2. Data Warehouse (Snowflake, BigQuery, Redshift) → recurring syncs.
3. APIs / Reverse ETL → Import API for custom pipelines.
 Historical Data (Optional)
• Recommended: Start fresh.
• If importing:
o Load into separate project.
o Use Segment Replay or Warehouse connectors.
o Expect ~5% data mismatch.

Mixpanel + Adobe Experience Platform (AEP)

• AEP can ingest Mixpanel data via Event Export API.
• Requirements:
o Valid Mixpanel account
o Project ID + credentials + timezone config
o Schema aligned with Mixpanel’s structure
• Secure communication via Bearer Tokens.
• Setup options: AEP UI or Flow Service API.

Data Layer in Adobe Analytics (for Mixpanel Users)

• Mixpanel: Send events + properties directly at action time.
• Adobe: Uses a data layer = structured JavaScript object (digitalData) on every page.
• Props & eVars pull values from this object.
Props = like event properties in Mixpanel (expire after hit).
eVars = sticky properties for attribution (persist until overwritten).

Example Data Layer (W3C Standard digitalData)

digitalData = {
pageInfo:{
pageName:'brand:region:country:language:t1:index',
seoStrategyPageName: 'home',
renderedExperience: 'large',
viewport: '942x561',
orientation: 'portrait'
}
};
Mapping Example
• digitalData.pageInfo.pageName → Adobe: Page (ch:na:us:en:t1:help-center:contact-us)
• digitalData.pageInfo.url → Adobe: URL (https://www.chevrolet.com/contact/call-us)
 • digitalData.pageInfo.pageType → Adobe: Page Type (model overview)

Implementation Notes
• Data layer standardizes variables across pages.
• Enables measurement of:
o Conversion effectiveness
o Bounce/exit rates
o Hierarchy-level performance
Direct Call Functions
• Trigger on non-page load actions.
Click Tracking
• Uses class + data-dtm attributes in HTML.
• Example:

<a class="stat-text-link" data-dtm="global nav">Shopping Tools</a>

Adobe Experience Manager (AEM)

• Adobe’s CMS for managing digital experiences.
• Key Features:
o Content authoring with drag & drop
o Manage websites, apps, personalized content
o Integrates with Adobe Analytics, Target, Campaign

FAQ Highlights
• s_account not defined → report suite not set in Launch.
• Validation → must be done by MRM team.
• QA timeline → at least 2 weeks before launch.
• jQuery (3.5.1+) required in source code for Adobe Launch custom conditioning.

Best Practices & Help

• Separate projects for live vs. historical data.
• Use Simplified Identity API.
• Add user profile properties from 3rd-party systems.
• Mixpanel’s CS team helps with migration + onboarding.

TL;DR
 • Mixpanel = simpler, faster, event-based.
• Adobe = structured, data-layer-based with props/eVars.
• Migrate with a fresh Mixpanel setup, optionally import past data.
• Push Mixpanel data into AEP for unified insights.
• Use a proper data layer (digitalData) in Adobe for consistency, flexibility, and future-proof
tracking.

Explaining Adobe Analytics Data Layer to

Mixpanel Users
1. What is a Data Layer?
• Adobe Analytics:
o Structured JavaScript object (digitalData or dataLayer) on every page.
o Acts as a single source of truth for page metadata, user info, product details.
o Variables inside are mapped to props (traffic variables) and eVars
(conversion variables).
• Mixpanel:
o No mandatory data layer.
o Events are defined and sent directly (mixpanel.track(“Event Name”,
{properties})).
o Flexible, but can become inconsistent without a schema.

2. Props and eVars in Adobe

• Props (Traffic Variables)
o Store page-level info (e.g., Page Name, Section).
o Always tied to the hit where they are set.
• eVars (Conversion Variables)
o Persist beyond a single hit (session or defined expiry).
o Example: If “Campaign ID” is captured, it can attribute later conversions.
• Events
o Explicit success metrics (e.g., purchase, form complete).
3. Mixpanel Equivalent
• Events = Adobe Events
• Properties = Props + eVars
o But persistence is manual in Mixpanel:
▪ If you want Adobe’s eVar-like behavior, you must attach that property
to every event where it should apply.
• Profiles
o Can be used for long-term attributes (similar to eVars that persist across
visits).

4. Why Adobe Users Want a Data Layer

• Centralizes data capture.
• Reduces reliance on developers for tagging each element.
• Ensures props/eVars are consistently populated.
• Easier debugging (check digitalData object in console).

5. Strategy for Using Both (Mixpanel + Adobe Data Layer)

• Maintain Adobe-style dataLayer as the source of truth.
• For Adobe: Map dataLayer values to props/eVars.
• For Mixpanel: Pull from the same dataLayer into mixpanel.track() calls.
• Benefits:
o Consistency across platforms.
o Cleaner governance (one schema to maintain).
o Easier onboarding for Adobe users transitioning to Mixpanel.

Key Analogy for Mixpanel Users

Think of the Adobe data layer as a well-organized toolbox:

• Props = tools you use once.

• eVars = tools you keep handy until the job is done.
• Data Layer = the toolbox itself, keeping everything in order.

A data layer is usually implemented as a JavaScript object in the website’s code. This
object acts like a container for all the important info the site wants to track.

For example, in code it might look like:

window.dataLayer = window.dataLayer || [];

window.dataLayer.push({
pageName: "Home Page",
userStatus: "Logged In",
productID: "12345",
productPrice: 49.99
});

• window.dataLayer creates the data layer object.

• push() adds information to it.
• You can keep pushing new info as the user navigates or interacts with the site.

Structured as digitalData, which is a common pattern used on websites to organize

tracking information.

Here’s why this qualifies as a data layer:

1. Structured, centralized information

• All key information about the page, visitor, vehicle, campaigns, etc., is stored in one
place (digitalData object).
• Example sections in your snippet:
o pageInfo → details about the page (name, type, URL, language, brand)
 o visitorProfile → info about the user (could include demographics, login
status, etc.)
o vehicleInfo → data about the vehicle being viewed
o internalCampaignInfo → tracking campaign details

2. Ready for analytics tools

• Tools like Adobe Analytics, Google Analytics, or Google Tag Manager can read
this object directly.
• Instead of scraping info from HTML elements, the analytics tool just reads from
digitalData.

3. Event-driven updates

• Often, the data layer also contains events, like a user clicking a button or adding a
product to a cart.
• In your example, you’re mostly seeing page-level data, but digitalData could
also be updated dynamically when interactions occur.

✅ Key takeaway

digitalData here is a classic data layer: it’s a structured JavaScript object that stores all
the info needed to track a page, a user, or interactions in a way that’s easy for analytics
tools to consume.

1. Page View Tracking

When a user lands on a page, Adobe Analytics needs to know what page they’re on and
other contextual info.

From your digitalData example, Adobe Analytics could pull:

Field in digitalData Used for in Adobe Analytics

pageInfo.pageName Page name (for reporting)
Page type (homepage, product page,
pageInfo.pageType
etc.)
pageInfo.brand Brand dimension
 pageInfo.region Geographic reporting
pageInfo.url Page URL
pageInfo.languageSel
Language dimension
ected

How it works technically:

1. Adobe Analytics code (AppMeasurement.js) reads digitalData.pageInfo.

2. It maps the values to sProps, eVars, and pageName in Adobe Analytics.
3. When s.t() (the page view tracking call) fires, all these values are sent to Adobe
Analytics.

Example (simplified):

s.pageName = digitalData.pageInfo.pageName;
s.channel = digitalData.pageInfo.pageType;
s.prop1 = digitalData.pageInfo.brand;
s.prop2 = digitalData.pageInfo.region;
s.t(); // fires the page view

2. Event Tracking

If the site wants to track user interactions (like clicks, form submissions, adding a car to a
comparison list), digitalData can include events.

Example of adding an event:

digitalData.event = {
name: "addToCompare",
vehicleID: "12345",
vehicleName: "Envision",
timestamp: new Date().toISOString()
};

// Adobe Analytics listens for this and triggers a tracking call

s.events = "event1"; // event1 mapped to “Add to Compare” in Adobe
s.eVar1 = digitalData.event.vehicleName;
s.tl(true, 'o', 'Add to Compare'); // fires custom link tracking

• s.tl() = “track link” call in Adobe Analytics (used for events not tied to a page
load)
• eVars = captures contextual info about the event
• events = records what happened

3. Benefits of Using the Data Layer

• Consistency: Analytics always reads the same structured info.

• Ease of maintenance: Updating the site structure doesn’t break analytics, as long
as digitalData is updated.
• Dynamic tracking: New events or page types can easily be added to the data layer
without changing Adobe Analytics code directly.

1. Data Layer Structure (JavaScript)

This is a template digitalData object for the configurator. Fields can be dynamically
populated based on the user’s interactions.

window.digitalData = window.digitalData || {};

window.digitalData = {
pageInfo: {
pageName: "equinox:us:configurator:step1", // dynamic per step
pageType: "configurator",
pageSubType: "",
brand: "Chevrolet",
model: "Equinox EV", // static or dynamic if other models
languageSelected: "EN",
url: window.location.href,
region: "North America"
},
visitorProfile: {
 visitorID: "", // unique ID if available
loggedInStatus: "", // "Logged In" / "Guest"
userType: "" // e.g., new vs returning
},
configuratorInfo: {
currentStep: "step1", // step in configurator
selectedTrim: "",
selectedColor: "",
selectedOptions: []
},
internalCampaignInfo: {
campaignName: "", // campaign reference
campaignSource: ""
},
events: []
};

2. Field Mappings to Adobe Analytics

Adobe Analytics
Data Layer Field Notes
Mapping
digitalData.pageInfo.pageName s.pageName Reports which page/step user is on
digitalData.pageInfo.pageType s.channel Page type dimension
digitalData.pageInfo.brand prop1 / eVar1 Brand dimension
digitalData.pageInfo.model eVar2 Model name
digitalData.configuratorInfo.curre Track user progress through
eVar3
ntStep configurator
digitalData.configuratorInfo.selec
eVar4 Selected trim
tedTrim
digitalData.configuratorInfo.selec
eVar5 Selected color
tedColor
digitalData.configuratorInfo.selec
eVar6 Optional features chosen
tedOptions
Custom events like clicks, adds,
digitalData.events events
completes
3. Event Triggers
Here’s how events should be pushed to the data layer and mapped to Adobe:

a) Launch Configurator (from MOVP CTA)

window.digitalData.events.push({
event: "configuratorLaunch",
timestamp: new Date().toISOString()
});

// Adobe call
s.events = "event1"; // Event1 = Configurator Launch
s.tl(true, 'o', 'Configurator Launch');

b) Step Change (e.g., selecting trim, color, options)

window.digitalData.configuratorInfo.currentStep = "step2";
window.digitalData.events.push({
event: "stepChange",
stepName: "step2",
timestamp: new Date().toISOString()
});

// Adobe call
s.events = "event2"; // Event2 = Step Change
s.eVar3 = "step2";
s.tl(true, 'o', 'Step Change');

c) Configuration Complete

window.digitalData.events.push({
event: "configuratorComplete",
configurationDetails: window.digitalData.configuratorInfo,
timestamp: new Date().toISOString()
});
// Adobe call
s.events = "event3"; // Event3 = Configurator Complete
s.eVar3 = window.digitalData.configuratorInfo.currentStep;
s.eVar4 = window.digitalData.configuratorInfo.selectedTrim;
s.eVar5 = window.digitalData.configuratorInfo.selectedColor;
s.eVar6 =
window.digitalData.configuratorInfo.selectedOptions.join(",");
s.tl(true, 'o', 'Configurator Complete');

4. Implementation Guidance for Metadome Developers

1. Place the data layer before Adobe AppMeasurement.js
a. Ensure the digitalData object exists before any Adobe tracking script
loads.
2. Populate fields dynamically
a. Update currentStep, selectedTrim, selectedColor, selectedOptions
as the user interacts.
b. Push events to the digitalData.events array whenever a tracked action
occurs.
3. Trigger Adobe Analytics calls after data layer update
a. Use s.t() for page views (initial launch).
b. Use s.tl() for interaction events (step change, complete).
4. QA / Validation
a. Test that all eVars/props/events populate correctly in Adobe Analytics debug
tools (e.g., Adobe Experience Cloud Debugger).
b. Validate that multi-step progress and configuration selections are correctly
captured.
5. Consistency across platforms
a. Ensure data layer naming matches existing GM standards so other
configurators can be analyzed uniformly.
Tagging Implementation Overview
• Successful analytics depends on four aligned layers: experience layer, unified data
layer, tagging plan, and data architecture.
• Misalignment can cause data loss, outages, or instability.
• The team ensures alignment via available resources in each layer and
communication about site updates.
• Tagging requirements are derived from critical analysis of data needs, leading to
strategic Tagging Plans for consistent tracking across sites.

What is a Tagging Plan?

• An Excel document outlining analytics requirements for developers/IT to add tags.
• Tags act as hooks/triggers for Adobe Launch or other analytics tools.
• Includes:
o Comps (visual representations of pages)
o Clickable elements to be tagged
o Relevant data layer fields or direct calls

Prerequisites for a Tagging Plan

1. SDR (Solution Design Reference)
a. Excel map of variables, data layer objects, and variable usage.
2. Comp or URL
a. Image, PDF, wireframe, or live URL of the page to be tagged.
3. Copy doc (optional if comps provided)
 a. Page text, section names, and clickable element descriptions.
4. Tagging Plan Templates
a. Standardized templates to save time and ensure alignment.

Building Blocks

Page-Level Tracking

• Analytics triggers on page load, form submission, or state changes.

• Data Layer: JavaScript object holding structured page and user info.
• Direct Calls: Functions firing tracking when page load isn’t available (e.g., SPAs,
shadow DOM).
• KPIs: Metrics for success, like completing a quote form or viewing search results.

Click-Level Tracking

• Analytics triggers on CTAs (buttons, links, interactive elements).

• Selectors: Class names to identify CTA types (stat-text-link, stat-icon-link, etc.).
• Location Data: data-dtm attributes identifying CTA location for reporting (prop27
= section, prop32 = section + link text).
• Site-to-site Parameters: Query strings to track cross-GM site navigation.

Variables
Typ
Purpose Notes
e
pro
Traffic variables Report on popularity; pathing available; not persistent
ps
eVa
Conversion variables Persistent; associate with success events; no pathing
rs
eve Success/Conversion Metrics for goal completions (purchases,
nts events subscriptions, etc.)
Common Tools/Extensions
• Awesome Screenshot & Screen Recorder: Flexible page capture and editing
• Snagit: Video/audio capture with screen recording
• PicPick / One Click Page Screenshot: Quick page screenshots

Key Takeaways

• A tagging plan ensures consistent, structured tracking.

• Requires coordination of data layer, page visuals, copy, and variable definitions.
• Differentiates between page-level and click-level tracking, using props, eVars, and
events.
• Tools like Adobe Launch read these tags to trigger analytics calls.

Analytics Tagging Cheat Sheet

Purpose
• Ensure consistent, accurate tracking of user interactions.
• Align data layer, tagging plan, and variable architecture.
• Prevent data loss, outages, or inconsistencies.
Key Components
1. Data Layer
a. JS object storing structured info about page, user, interactions.
b. Example: digitalData.pageInfo.pageName,
digitalData.configuratorInfo.currentStep.
2. Tagging Plan
a. Excel document communicating analytics requirements to developers.
b. Includes: page comps, clickable elements, required tags, and data layer
references.
3. Variables | Type | Purpose | Notes | |------|--------|------| | props | Traffic/popularity |
Not persistent, pathing possible | | eVars | Conversion/persistent data | Associates
with success events | | events | Success metrics | Goal completions like clicks or
submissions |
4. Page-Level vs Click-Level
• Page-Level: Page loads, form submissions, state changes.
• Click-Level: CTA interactions (buttons, links, icons).
• Selectors: Class names (e.g., stat-text-link) identify CTA types.
• Location Data: data-dtm maps to prop27 (section) & prop32 (section + link).

Event Tracking
• Page Load: s.t() call to fire page view
• CTA / Interaction: s.tl() call to fire events
• Dynamic updates: Push events to digitalData.events before Adobe call

Prerequisites for Tagging Plan

• SDR: Variable map & data layer definitions
• Comp or URL: Page visuals/wireframes
• Copy doc (optional): Text copy & link destinations
 • Tagging templates: Standardized for ad-hoc or sustain plans

KPIs
• Vehicle search results views
• Quote request completions
• Configurator step progress

Site-to-Site Parameters
• Query strings appended to URLs to track visits between GM sites
• Helps identify traffic source and navigation path

Common Tools
• Awesome Screenshot & Screen Recorder – Capture full pages, edit, annotate
• Snagit – Record screen, audio, and video
• PicPick / One Click Page Screenshot – Quick screenshots

Quick Tip
Keep the data layer structured and updated. Even without Adobe, this allows other
analytics tools (Mixpanel, GA4) to consume consistent tracking data.