MediaMath Pixel Tracking and TerminalOne API Reference | OpsBlu Docs

MediaMath Pixel Tracking and TerminalOne API Reference

Technical reference for MediaMath mt.js pixel deployment, conversion events, audience segments, and TerminalOne API integration.

Platform Discontinued: MediaMath ceased operations and filed for bankruptcy in June 2023. This page is retained as a technical reference for teams migrating off MediaMath infrastructure or auditing legacy implementations. For active DSP alternatives, see The Trade Desk, Google DV360, or Adobe Advertising Cloud.

How MediaMath Tracking Worked

MediaMath's tracking infrastructure centered on the mt.js pixel library, loaded from pixel.mathtag.com. The pixel identified users through a combination of third-party cookies (stored under mathtag.com) and sync partnerships with major ad exchanges.

When the mt.js pixel loaded on a page:

  1. Read or set the mt_mop cookie containing the MediaMath user ID
  2. Fired a cookie-sync chain to exchanges (AppNexus, Google, Index Exchange) to map the MediaMath ID to exchange-specific IDs
  3. Sent the page event (page view, conversion, segment qualification) to pixel.mathtag.com/event/js
  4. Returned a 1x1 transparent GIF or empty response

The TerminalOne (T1) platform consumed this event data to:

  • Build and update audience segments in real time
  • Attribute conversions to specific campaigns, strategies, and creatives
  • Feed the bidding engine with recency and frequency signals

MediaMath's DMP integration allowed combining first-party pixel data with third-party audience segments from providers like Oracle Data Cloud, Lotame, and Eyeota.

Installing the MediaMath Pixel (mt.js)

The base pixel was placed on every page:

<script src="https://pixel.mathtag.com/event/js?mt_id=YOUR_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=&v2=&v3=&s1=&s2=&s3=" type="text/javascript"></script>

Parameters:

  • mt_id -- The pixel ID (unique per tracking pixel, created in T1)
  • mt_adid -- The advertiser ID in TerminalOne
  • v1, v2, v3 -- Custom value fields (used for revenue, order ID, product ID)
  • s1, s2, s3 -- Custom segment fields (used for audience qualification)

For asynchronous loading:

<script type="text/javascript">
(function() {
  var mt = document.createElement('script');
  mt.type = 'text/javascript';
  mt.async = true;
  mt.src = 'https://pixel.mathtag.com/event/js?mt_id=YOUR_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=&v2=&v3=&s1=&s2=&s3=';
  var s = document.getElementsByTagName('script')[0];
  s.parentNode.insertBefore(mt, s);
})();
</script>

For environments where JavaScript was not supported, a noscript image fallback was used:

<noscript>
<img src="https://pixel.mathtag.com/event/img?mt_id=YOUR_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=&v2=&v3=&s1=&s2=&s3=" width="1" height="1" alt="" />
</noscript>

Conversion Tracking

Conversion events were tracked by firing the mt.js pixel with populated value fields on specific pages or actions.

Purchase Conversion

<script src="https://pixel.mathtag.com/event/js?mt_id=CONV_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=ORDER_TOTAL&v2=ORDER_ID&v3=CURRENCY&s1=purchase&s2=&s3=" type="text/javascript"></script>

Example with dynamic values:

<script type="text/javascript">
var orderTotal = 149.99;
var orderId = "ORD-12345";
var img = new Image();
img.src = "https://pixel.mathtag.com/event/img?mt_id=54321&mt_adid=98765&v1=" + orderTotal + "&v2=" + orderId + "&v3=USD&s1=purchase";
</script>

Lead Generation Conversion

<script src="https://pixel.mathtag.com/event/js?mt_id=LEAD_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=1&v2=LEAD_ID&v3=&s1=lead_submit&s2=&s3=" type="text/javascript"></script>

Custom Funnel Events

MediaMath supported arbitrary event tracking by using different mt_id values for each stage:

<!-- Product View -->
<script src="https://pixel.mathtag.com/event/js?mt_id=PV_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=PRODUCT_ID&v2=CATEGORY&v3=PRICE&s1=product_view" type="text/javascript"></script>

<!-- Add to Cart -->
<script src="https://pixel.mathtag.com/event/js?mt_id=ATC_PIXEL_ID&mt_adid=YOUR_ADVERTISER_ID&v1=PRODUCT_ID&v2=QUANTITY&v3=PRICE&s1=add_to_cart" type="text/javascript"></script>

Each event type required a separate pixel ID created in the TerminalOne UI under Advertiser > Pixels.

Audience Segments

MediaMath audience segments were built through three mechanisms:

Pixel-Based Segments

The s1, s2, s3 parameters in the pixel URL assigned users to named segments. When the pixel fired with s1=cart_abandoner, any user who triggered that pixel was added to the cart_abandoner segment in T1.

Segment membership had a configurable TTL (time-to-live), defaulting to 30 days. After TTL expiration, the user was automatically removed from the segment.

TerminalOne Segment Rules

In the T1 UI, segments could be defined with boolean logic combining pixel events:

  • Users who fired product_view AND add_to_cart but NOT purchase in the last 14 days
  • Users who fired purchase with v1 (order total) greater than 200

Third-Party DMP Segments

MediaMath integrated with external DMPs (Oracle Data Cloud, Lotame, Eyeota, LiveRamp) for:

  • Demographic targeting -- Age, gender, income, education
  • Interest/intent segments -- In-market auto buyers, travel intenders
  • CRM onboarding -- First-party customer lists matched via LiveRamp or Oracle

Third-party segments were activated in T1 campaign setup under Audience > Third Party Data.

TerminalOne API Integration

The TerminalOne API provided programmatic access to campaigns, reporting, and audience management.

Authentication

# Session-based auth
curl -X POST "https://api.mediamath.com/api/v2.0/session" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "user=YOUR_USERNAME&password=YOUR_PASSWORD"

# Returns session cookie for subsequent requests

Campaign Management

# List campaigns for an advertiser
curl -X GET "https://api.mediamath.com/api/v2.0/campaigns?advertiser_id=98765" \
  -H "Cookie: adama_session=SESSION_TOKEN"

# Create a new campaign
curl -X POST "https://api.mediamath.com/api/v2.0/campaigns" \
  -H "Cookie: adama_session=SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Q1 Retargeting",
    "advertiser_id": 98765,
    "start_date": "2023-01-01T00:00:00Z",
    "end_date": "2023-03-31T23:59:59Z",
    "total_budget": 50000.00,
    "goal_type": "CPA",
    "goal_value": 25.00
  }'

Reporting API

# Pull campaign performance report
curl -X POST "https://api.mediamath.com/reporting/v1/std/performance" \
  -H "Cookie: adama_session=SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": {
      "advertiser_id": 98765,
      "campaign_id": [12345]
    },
    "time_rollup": "by_day",
    "time_window": "last_30_days",
    "dimensions": ["campaign_name", "strategy_name"],
    "metrics": ["impressions", "clicks", "total_conversions", "total_spend", "cpa"]
  }'

Pixel Management API

# List all pixels for an advertiser
curl -X GET "https://api.mediamath.com/api/v2.0/pixel_bundles?advertiser_id=98765" \
  -H "Cookie: adama_session=SESSION_TOKEN"

# Create a conversion pixel
curl -X POST "https://api.mediamath.com/api/v2.0/pixel_bundles" \
  -H "Cookie: adama_session=SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "advertiser_id": 98765,
    "name": "Purchase Conversion",
    "pixel_type": "event",
    "tag_type": "js"
  }'

Common Issues (Legacy Reference)

MediaMath's cross-exchange identity resolution depended on cookie-sync chains. When browsers blocked third-party cookies (Safari ITP, Firefox ETP), the mathtag.com cookie could not be set, breaking:

  • User identification across sessions
  • Cross-exchange audience matching
  • Frequency capping accuracy

This was a systemic issue that MediaMath never fully resolved before shutdown.

Pixel Firing Order

If the conversion pixel fired before the base pixel on a user's first visit, the user lacked a mt_mop cookie and the conversion could not be attributed. The base pixel had to fire first to establish identity.

v1/v2/v3 Parameter Encoding

Special characters in value parameters (ampersands, equals signs, spaces in product names) broke the pixel URL if not properly URL-encoded:

// Correct: encode dynamic values
var productName = encodeURIComponent("Widget & Gadget Pack");
img.src = "https://pixel.mathtag.com/event/img?mt_id=54321&mt_adid=98765&v1=" + productName;

TerminalOne API Rate Limits

The T1 API enforced rate limits of approximately 10 requests/second per session. Bulk operations (pulling reports for hundreds of campaigns) required pagination and throttling. The reporting API had a separate queue with longer response times (30-120 seconds for complex queries).

Conversion Deduplication

MediaMath deduplicated conversions based on the v2 field (typically order ID). If v2 was empty or non-unique, duplicate conversions were counted. There was no server-side deduplication window -- duplicates had to be prevented at the pixel level.

Migration Guidance

Since MediaMath's shutdown, the primary migration paths are:

The Trade Desk -- Closest feature parity for programmatic buying. Supports similar pixel-based tracking (ttd_universal_pixel), audience segmentation, and API-driven campaign management. Most MediaMath audience segments can be rebuilt using TTD's Universal Pixel events.

Google DV360 -- Strong option for teams already in the Google ecosystem. DV360's Floodlight tags replace MediaMath's mt.js pixels. Campaign structure (Advertiser > Campaign > Insertion Order > Line Item) maps roughly to MediaMath's (Advertiser > Campaign > Strategy > Concept).

Adobe Advertising Cloud -- Best for organizations using Adobe Analytics and Experience Cloud. Conversion tracking moves to Floodlight/AMO ID. Audience segments migrate to Adobe Audience Manager or Analytics-based segments.

For all migration paths, the key steps are:

  1. Export all historical reporting data from T1 (no longer accessible post-shutdown -- use any archived exports)
  2. Recreate audience pixel events on the new platform
  3. Rebuild audience segments using equivalent logic
  4. Redirect any hardcoded pixel URLs (pixel.mathtag.com) to the new platform's tracking endpoints or remove them entirely
  5. Update any server-side integrations that called the T1 API
返回顶部