growth data-systems audit

Why analytics at a derivatives exchange is harder than at a normal app

The JD reads as one job but is really three distinct skill sets, and interviews will probe each. The combination is uncommon: most analytics people don't write Terraform; most engineers don't think in funnels.

I fetched bitmex.com and read the page bundle. What I could verify from outside, and what's inferred from the JD - kept clearly separate.

The failure modes this role exists to prevent. None throw an error - they just produce a confident, wrong number. Each maps to a fix later in the deck.

What I'd do in the first two weeks - low-risk, high-signal, and each one builds trust before touching anything load-bearing.

The deliverable the JD names directly. A tracking plan is a contract: Object-Action naming, typed properties, one owner, versioned in git, enforced by Segment Protocols so a malformed event is blocked at the edge - not discovered three weeks later in a broken Mixpanel funnel.

A slice of the plan I'd write for the core funnel

The single most important design call in the whole stack, and the one that fixes most of the §04 failure modes.

The unusual JD requirement, and the strongest signal of what they want: most analytics teams click around in dashboards; this one wants the stack in version control. The reasoning: manual config in a UI produces an analytics stack nobody can review, reproduce, or roll back.

# segment/destinations.tf - a destination as reviewable code (illustrative)
resource "segment_destination" "mixpanel_prod" {
  source       = segment_source.web_ui.id
  name         = "Mixpanel - Production"
  enabled      = true
  metadata_id  = data.segment_destination_metadata.mixpanel.id

  settings = jsonencode({
    apiSecret   = var.mixpanel_api_secret   # from secrets manager, never in git
    token       = var.mixpanel_token
    people      = true
    setAllTraitsByDefault = false       # explicit traits only - no PII leakage
  })
}

# a change to this destination is now a pull request:
#   terraform plan  →  review the diff  →  apply on merge  →  audit trail for free

Illustrative of the segmentio/segment provider, which wraps Segment's Public API - so each destination's settings schema differs and API rate limits apply on bulk applies. Two gotchas to plan for up front: Terraform state stores destination secrets in plaintext → encrypted remote backend (S3+KMS / TF Cloud) with state locking, never local state; and any resource already created in the UI must be terraform import-ed before the first apply or it gets clobbered.

"Deep-linking and postbacks" in the JD = AppsFlyer. At a privacy-heavy crypto exchange this is the hardest part of the stack, and where deterministic tracking has mostly died - so the design has to be server-to-server first.

"Monitor and audit pipelines to prevent inaccurate dashboards." The interview version of this is almost always some flavour of the reconciliation question - here's the structured answer I'd give, which doubles as the runbook I'd actually build.

Talk is cheap - here are the actual artifacts behind the blueprint. The theme throughout: make the schema impossible to violate by accident, and make money events reliable.

1 · A typed tracking layer (TS) - the schema enforced by the compiler

// events.ts - the tracking plan, as types. A typo or missing prop won't compile.
type EventMap = {
  'Deposit Completed': { amount_usd: number; asset: string; method: string; is_first: boolean }
  'Order Filled':      { symbol: string; contracts: number; notional_usd: number; fee: number }
  'KYC Approved':      { tier: 'basic' | 'advanced'; days_since_signup: number }
}

export function track<K extends keyof EventMap>(event: K, props: EventMap[K]) {
  // one funnel for every event → impossible to fire an off-plan name or shape
  analytics.track({ event, properties: props })
}

track('Deposit Completed', { amount_usd: 500, asset: 'USDT', method: 'onchain', is_first: true })
// track('Deposit Completed', { amount: 500 })  ❌ won't compile - wrong shape, caught in CI

2 · Server-side money event, idempotent (Node) - can't be blocked, can't double-count

import { Analytics } from '@segment/analytics-node'
const analytics = new Analytics({ writeKey: process.env.SEGMENT_SERVER_KEY })

export async function onDepositCredited(deposit) {
  analytics.track({
    userId:    deposit.userId,
    event:     'Deposit Completed',
    properties:{ amount_usd: deposit.usdValue, asset: deposit.asset, method: deposit.method, is_first: deposit.isFirst },
    // deterministic id from the domain key → a retry collapses to ONE event, not two
    messageId: `deposit:${deposit.id}`,
    timestamp: deposit.creditedAt,
  })
}

3 · React route + funnel tracking hook - consistent Page calls, zero per-page boilerplate

function usePageTracking() {
  const { pathname } = useLocation()
  useEffect(() => {
    window.analytics?.page({ path: pathname })   // one place, every route, never forgotten
  }, [pathname])
}

Plus the integration piece the JD asks for: a small Node webhook receiver that takes events from internal services and forwards them into Segment with retries + the same idempotency rule - the "backend-to-third-party" glue, written once and reused.

Sequenced deliberately: earn trust by making the existing numbers correct first, then add governance, then extend to attribution. No load-bearing change before the stack is captured as code.

Claims are split into confirmed (verified live from the public site) and inferred (from the JD) throughout. Code snippets are illustrative of approach, not production config. This is an unsolicited audit prepared as interview homework - happy to walk through any section live.

Prepared by Edward Tay · for the BitMEX Growth Engineer (Data Systems) role · Jun 2026