TraderArea DataLayer

§1 Principle

Push facts, not offers

We agree with making this global rather than building it around a single breach event, and we have gone further in that direction: phase 1 is one event.

Axcera pushes facts about the user and their accounts. Status, timestamps, plan, size, counts. These change rarely and are stable to implement against.

Top One decides what is shown. Which traders see a prompt, what it says, what it offers, for how long, and when it stops. That logic changes weekly during a campaign, and every one of those changes should cost you nothing.

If a field would ever need updating because we changed a promotion, it is on the wrong side of the line. Nothing in this document carries a price, a discount, a coupon, a deadline or an eligibility rule.

§2 Shape

One snapshot event, re-pushed whenever the facts change

A single event, topone_context, carrying a complete snapshot under its own topone namespace. It is a picture of the current state, never a "something just happened" signal. We derive everything we need from it, including whether an account is breached.

// Initialise once, before the first push. Never reassign an existing dataLayer.
window.dataLayer = window.dataLayer || [];

// Clear only our namespace, then push a COMPLETE snapshot. GTM keeps the last value of any
// key that a later push omits, so a partial push would let a stale account list survive.
window.dataLayer.push({ topone: null });
window.dataLayer.push({
  event: "topone_context",
  topone: {
    schemaVersion:  1,
    brand:          "topone_futures",
    environment:    "production",
    pageInstanceId: "9c1f4e2a",          // new per full page load
    sequence:       12,                  // increases with every push in this page instance
    observedAt:     "2026-09-08T18:00:00Z",
    page:  { navigationId: "n_0007", type: "account_detail", state: "ready" },  // navigationId: new per client-side navigation
    user: {
      userId:            "5f3a9c1e2b7d4a6081c2e9f0",
      accountsTotal:     7,
      accountsActive:    2,
      accountsBreached:  4,
      accountsFunded:    1,
      breachesLifetime:  9,
      firstPurchaseAt:   "2026-03-11T09:02:14Z",
      lastPurchaseAt:    "2026-09-02T16:27:41Z"
    },
    account: {                            // the account in context, else null
      accountId:    "64d1f0a2b3c4e5f6a7b8c9d0",
      accountNr:    "TOF-PX-100001",
      status:       "breached",
      phase:        "evaluation",
      planId:       "elite-daily-50k",
      plan:         "Elite Daily | $50,000",
      accountSize:  50000,
      platform:     "tradovate",
      createdAt:    "2026-08-29T21:40:03Z",
      breachedAt:   "2026-09-03T10:30:00.412Z",  // native precision, never truncated
      isReset:      false,               // native meaning: a reset was performed on this account
      resetTo:      null,                // replacement account id once reset
      resetAt:      null,
      isRepeated:   false,  repeatedTo: null,
      isUpgraded:   false,  upgradedTo: null,
      updatedAt:    "2026-09-08T17:58:41.007Z"  // when your record last changed
    },
    accounts:      null,                   // array of the same objects on list pages
    accountsScope: "not_loaded"            // "all" | "visible_page" | "not_loaded"
  }
});

When to push it

• Navigation start. The moment a client-side navigation begins, push a snapshot with a new page.navigationId, page.state: "loading", account: null and accountsScope: "not_loaded". This is what takes a prompt down instantly; nothing else can.
• Ready. When the authenticated user and the accounts the new route needs have resolved, push again with the same navigationId and page.state: "ready". Discard any account response that belongs to an earlier navigation instance instead of pushing it: a higher sequence cannot make an old response current.
• Every client-side route change, including account A to account B on the same route type. The TraderArea is a single-page app; without the loading and ready pair the context goes stale as the trader navigates.
• Whenever account facts change. A breach, reset or activation that arrives by polling or WebSocket while the dashboard is open should trigger a fresh push. Otherwise an open tab keeps a prompt alive after the account was already reset.
• Entering checkout or payment routes. Push with page.type: "checkout" and the account context cleared. Silence cannot remove a prompt that is already on screen; a snapshot can. Route type is a fact; whether marketing belongs there is our decision.
• Logout or user switch. Push with user: null so anything on screen is removed and nothing is attributed to the wrong person.

Every push carries all of user, account and accounts, using null when not applicable. accountsScope says whether an array is the whole portfolio, one visible page, or not loaded at all; an empty array [] means a known empty result. The counts on user are backend totals and never depend on what is visible.

§3 Fields

Envelope

User object

Account object

Please serialise only the fields agreed here rather than your whole API object, so a future field added to your API does not silently become part of this contract.

§4 Later

Transition events, only where a snapshot cannot express them

Phase 1 needs none of these. They are listed so the envelope you build now accommodates them without a second design round. Each is a moment in time and must carry its own occurrence id, because an account object alone cannot distinguish two payouts or two breaches.

Anything that must be captured while the trader is offline, such as a reset or payout for durable history, belongs in a server-to-server webhook rather than the browser. That is a separate conversation and does not affect phase 1.

§5 Pages

Every authenticated route, including the ones we will not act on

The snapshot fires on every authenticated TraderArea route. We would rather receive it on checkout and payment pages with page.type saying so than receive nothing there, because nothing cannot take a prompt down. Our tag suppresses on those types and removes anything already mounted.

The routes where a prompt will actually appear are the dashboard, the account list and the account detail page, with that account in account so a prompt can be specific to the one the trader is looking at.

§6 Conventions

Details that save a round trip

• Timestamps ISO 8601 in UTC at your native precision, matching your read API. Never truncated, never a preformatted local string.
• Numbers plain integers. Sizes in whole US dollars. Counts as integers.
• Identifiers always strings, even when they look numeric.
• Enums we need the complete value list for status, phase, platform, planId and page.type before the first test.
• Missing null means unknown or not applicable. It is never a stand-in for false, 0 or an empty list.
• Stability adding a key is safe. Renaming, retyping, changing nullability or changing what a value means is a new schemaVersion; tell us before it ships.
• Ordering we act only on the highest sequence seen for the current pageInstanceId and navigationId, and discard anything older, from a previous navigation, or from a previous user.

§7 Our side

What Top One commits to, so you can hold us to it

• One controller, not many tags. A small GTM Custom HTML loader pulls a versioned Top One script. The version is pinned in the container so a rollback rolls back the behaviour too. It initialises once and consumes every snapshot; it does not fire on page views or timers.
• Deterministic selection. If several accounts qualify, one prompt is shown: the account in context first, otherwise the most recent breach. Never stacked prompts.
• Identity before offers. Our endpoint answers only a request that carries a valid short-lived assertion of who is asking (section 9, item 6). Your read API can confirm that an account belongs to a user; it cannot tell us that the browser making the request is that user, and those are two separate checks. The assertion travels straight from your endpoint to ours and never through the dataLayer.
• Server-owned offers. With identity established, our endpoint validates the account and its current state against your read API and issues an offer instance with a server deadline. The checkout retrieves that same instance. A deadline is never restarted by a refresh, a second device or entering checkout, and expiry is enforced at checkout regardless of what the browser shows. The countdown is anchored to server time.
• Caps on our server. Browser storage is a local convenience only. One impression per campaign per breach occurrence, plus a user-wide cooldown, is kept server-side keyed by userId and the breached accountId, so a second device does not show it again.
• Vendor strings are text. Account numbers and plan names are rendered as text nodes, never interpolated into markup or script. Links go only to approved Top One origins.
• Unknown values suppress. A status or plan we do not recognise turns the campaign off for that account and alerts us. We never map by guesswork.
• Consent and content. The tag respects the site's consent state and removes itself on withdrawal. Deadlines are real, discount baselines are accurate, reset scope and fees are stated plainly, and nothing suggests a reset recovers losses. Creative, terms and the deadline rule are archived per campaign.
• Privacy. userId is pseudonymous personal data and is kept out of advertising tags. No email, hashed or otherwise, is in this contract. Only fields we explicitly allowlist are forwarded to analytics; nothing here is forwarded by default.

§8 First test

Smoke test, then acceptance

1. You embed GTM-K7XMHV9M on the Futures TraderArea and implement topone_context with the phase 1 fields.
2. You send us one named test account, its id, and confirm it is on our server allowlist, so the offer endpoint answers only for that user during testing.
3. We verify in GTM Preview, which stays scoped to our session, and confirm every field back to you.
4. We build the tag, keep it in Preview until it is right, then publish behind a kill switch.

The single-account test proves the plumbing. Before we widen it, we will exercise on our side: first breach, reset, second breach on the replacement account; account A to account B with a slow response for A still in flight; several breached accounts and a paginated list; detail to dashboard to checkout; logout and login as another user; slow or out-of-order responses while the dashboard stays open; two tabs and two devices; storage unavailable; expiry during checkout and a duplicate redemption attempt; and the published CSP outside Preview. Agreed that testing happens on production and that anything published is live immediately.

§9 Back to you

What we need before the first test

1. Install the Futures container. portal.toponefutures.com loads no GTM today. Please embed GTM-K7XMHV9M on the Futures tenant (head snippet plus noscript frame, as on Trader) and tell us which routes, if any, are excluded. The container lives in Top One's account and publish rights stay with our team.
2. Enum values for status, phase, platform, planId and page.type.
3. Reset semantics. Confirm the native meaning of isReset, resetTo and resetAt with a concrete example of each: a first breach, a completed reset, a second breach, and a reset that creates a replacement account. We will adopt your meaning rather than impose one.
4. Refresh channels. Which changes reach an open dashboard by polling or WebSocket, and can the snapshot be re-pushed when they land?
5. Content Security Policy. The policy actually enforced on the TraderArea: whether GTM runs with a nonce, and what script-src, style-src, connect-src, img-src and font-src allow. Our loader, its stylesheet and our offer endpoint need to be permitted, and Preview mode has its own requirements.
6. Identity we can trust. Required, not optional. A browser-supplied userId is not authentication, and your read API can confirm ownership but not who is asking. We need one of: a same-origin endpoint on the TraderArea that returns a short-lived signed assertion for the logged-in session (a JWT over userId and tenant, audience topone-offers, about five minutes, keys held server-side on both ends), which our script passes directly to our endpoint and never into the dataLayer; an authenticated proxy on your side; or an existing session mapping we can verify. The assertion proves identity only; eligibility is still checked live.