mParticle vs Hightouch

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Hightouch
   mParticle—none0/10

   No evidence of an llms.txt file or agent-oriented documentation format; all citations point to standard human-facing docs pages with no mention of AI-agent discoverability tooling. missing for 10: llms.txt file, agent-oriented doc structure, any mention of AI-agent/LLM crawling support.

   ⚑ flag

   Hightouch✓fullprobed9/10

   A live llms.txt is confirmed at https://hightouch.com/llms.txt (HTTP 200), explicitly framing Hightouch as an 'Agentic Marketing Platform' and indexing its docs for agent consumption, corroborated by a runtime probe. This directly satisfies the story of pointing an agent at agent-oriented docs. Missing for 10: no docs.md/markdown-mirror endpoint (404) or OpenAPI spec discovery, which would round out full agent-native doc coverage.

   • [probe] “PROBE llms.txt: HTTP 200 at https://hightouch.com/llms.txt # Hightouch > Hightouch is an Agentic Marketing Platform powered by the industry…”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”
   • [probe] “PROBE docs-md: HTTP 404 at https://hightouch.com/docs.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Hightouch
   mParticle~partialprobed5/10

   mParticle exposes multiple HTTP APIs (server-to-server Events API, Warehouse Sync API, Platform Audiences API) that can be invoked programmatically without a UI, and the probe confirms the events API is live, auth-gated, and the SDK installs headlessly via npm — enabling scripted/automated data operations suitable for CI-like pipelines. However, there is no evidence of a dedicated CLI, infrastructure-as-code tooling, or documented CI/CD integration patterns specifically for automation workflows. Missing for 10: a CLI or IaC tool, explicit CI/CD pipeline examples, and independent hands-on confirmation of full headless workflows beyond event ingestion.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Real-time API to drive user personalization”
   • [claimed-docs] “Audiences”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch~partialprobed6/10

   Hightouch exposes a REST API (auth-gated, verified live) for syncs/models/sources/destinations and supports Git Sync for programmatic resource management, both enabling scripted/CI-driven workflows. However, there's no dedicated CLI, no documented CI/CD pipeline examples, and syncs are primarily scheduled/triggered rather than designed for headless orchestration. missing for 10: official CLI tool, documented CI/CD integration examples or GitHub Actions templates, evidence of headless batch/automation runs outside the API, independent hands-on confirmation of CI usage.

   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Git Sync lets you manage workspace resources programmatically.”
   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”
   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round drawn
   mParticle—none0/10

   No evidence of an official CLI tool; only SDKs, REST/HTTP APIs, and web dashboard workflows are documented. missing for 10: any mention of an official mParticle CLI, its installation, command reference, or usage examples.

   ⚑ flag

   Hightouch—none0/10

   The evidence pack covers Hightouch's REST API, Git Sync, and MCP server for AI assistants, but no official CLI tool is mentioned anywhere in the docs, pricing, or community evidence. Since Hightouch is a developer-facing data platform where a CLI would be a plausible and expected offering, its absence constitutes 'none' rather than 'na'.

   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Git Sync lets you manage workspace resources programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hightouch.com/openapi.json, https://hightouch.com/swagger.json, https://hightouch.com/api/op…”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   mParticle✓fullprobed8/10

   mParticle documents extensive public APIs (Events API, Warehouse Sync API, Platform API for audiences, Client SDKs) and a probe confirms the server-to-server events API is live and auth-gated as documented, with the official SDK installable via npm. missing for 10: independent third-party developer accounts of building full integrations via the API beyond the single probe, and no explicit API reference/versioning/SLA documentation cited.

   • [claimed-docs] “Send events directly to mParticle”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Client SDKs”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch✓fullprobed8/10

   Hightouch documents a REST API covering syncs, models, sources, and destinations with bearer-token authentication, and a runtime probe confirms the API is live and properly auth-gated. This gives AI-native users a real programmatic surface beyond the UI/MCP layer. Missing for 10: a discoverable OpenAPI/Swagger spec (probed and 404) and independent developer corroboration of API robustness.

   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hightouch.com/openapi.json, https://hightouch.com/swagger.json, https://hightouch.com/api/op…”

   proof ↗⚑ flag

5. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Hightouch
   mParticle—none0/10

   Evidence only shows basic key/secret authentication gating mParticle's events API (401 on keyless POST), with no mention of scoped, least-privilege, or agent-specific credential issuance mechanisms.

   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”
   • [claimed-docs] “Warehouse Sync API Overview”

   proof ↗⚑ flag

   Hightouch~partialprobed4/10

   Hightouch supports bearer-token API keys for its REST API and permissions/RBAC/ownership boundaries, and MCP access is described as scoped to workspace RBAC, but there is no documented mechanism for issuing scoped, least-privilege, agent-specific credentials (e.g., per-agent API keys, granular scopes, or token minting for agents). missing for 10: dedicated scoped/least-privilege credential issuance for agents, documentation of API key scopes/permissions granularity, evidence of per-agent or short-lived token support.

   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”
   • [claimed-docs] “Set up permissions, approvals, and ownership boundaries so each team has the right level of access.”
   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round drawn
   mParticle✓fullprobed7/10

   mParticle publishes official client SDKs and a documented events API (docs-17, docs-1/2), and a live runtime probe confirms the @mparticle/web-sdk is installable from npm and the server-to-server events API is auth-gated and functioning as documented (mparticle-probe-rt-1). This shows a real, working official SDK/API surface a developer (AI-native or otherwise) can build against. Missing for 10: independent/hands-on corroboration beyond a single probe, and no detail on breadth of language/platform SDK coverage or AI-specific SDK tooling.

   • [claimed-docs] “Client SDKs”
   • [claimed-docs] “Send your first event to mParticle”
   • [claimed-docs] “Send events directly to mParticle”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch✓fullprobed7/10

   Hightouch documents official SDKs for browser, iOS, Android, Node.js plus an HTTP API for event ingestion, and a separate authenticated REST API for managing syncs/models/sources/destinations, giving AI-native builders multiple official, documented integration surfaces. Missing for 10: a publicly discoverable OpenAPI/swagger spec (probe shows 404s across candidate paths) and independent/hands-on developer corroboration of SDK reliability beyond vendor docs.

   • [claimed-docs] “Hightouch provides SDKs for browser, iOS, Android, Node.js, and other platforms, plus an HTTP API for server-side ingestion”
   • [claimed-docs] “Hightouch provides SDKs for [browser](/docs/events/sdks/browser), [iOS](/docs/events/sdks/ios), [Android](/docs/events/sdks/android), [Node.…”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”
   • [claimed-docs] “You instrument your app, site, or backend with a Hightouch SDK, the HTTP API, or a streaming source like Kafka or Google Pub/Sub.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hightouch.com/openapi.json, https://hightouch.com/swagger.json, https://hightouch.com/api/op…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   mParticle—none0/10

   mParticle's evidence covers event ingestion, audiences, integrations, and outbound partner connections, but nothing describes a webhook subscription mechanism for consuming events out of mParticle. Missing for 10: any documented webhook endpoint registration, event subscription API, or push-notification mechanism for external/AI consumers.

   ⚑ flag

   Hightouch—none0/10

   Evidence shows sync alerts/notifications (docs-28) and a REST API (docs-13, docs-33) but no documentation of a webhook subscription mechanism for events; Hightouch Events (docs-5/6/7) is about ingesting customer behavior data, not emitting webhooks for system/sync events. No evidence of an outbound webhook API or subscription endpoint for AI agents to consume.

   • [claimed-docs] “Get notified when a run fails [Configure sync alerts]”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Hightouch Events collects customer behavior from websites, mobile apps, and backend systems, then stores that data in your warehouse.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Hightouch
   mParticle~partialclaimed5/10

   mParticle's marketing docs describe a natural-language audience-building feature where you 'describe the audience, journey, or growth goal' and the product 'suggests the logic to use,' plus churn/value scoring — both are AI-generated suggestion capabilities inside the product. However, this is vendor-only marketing copy with no technical documentation, UI walkthrough, or independent/hands-on corroboration of how these AI suggestions actually work or perform. Missing for 10: independent or hands-on verification, technical docs on the underlying models, broader coverage of AI insights beyond audience-building.

   • [claimed-docs] “Score likelihood to churn, convert, or grow in value, then activate audiences before risk or opportunity passes.”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Hightouch documents a 'built-in agent' to explore segments and analyze campaign performance in natural language (hightouch-docs-19) and an AI Decisioning feature that uses reinforcement learning to recommend messages/channel/timing (hightouch-docs-14), which are AI-generated insights/suggestions surfaced in-product. However, most evidence emphasizes agentic actions (building audiences, syncs, generating ad creatives) via MCP rather than analytical insights/recommendations presented directly in the UI, and there's no independent/hands-on corroboration of the insights quality. missing for 10: independent verification of the built-in agent's insight/recommendation quality, more detail on how insights are surfaced in-product (dashboards, reports) beyond brief doc mentions, and hands-on evidence of AI Decisioning's real-world recommendation accuracy.

   • [claimed-docs] “AI Decisioning uses reinforcement learning to recommend the best message, channel, and timing for each customer, then measures what worked.”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Hightouch
   mParticle~partialclaimed5/10

   mParticle supports background automations such as audience computation/activation to connected outputs, warehouse sync ingestion on schedules, and consent-based forwarding rules that run without manual intervention once configured. However, there is no evidence of AI-agentic or autonomously self-directed automation (e.g., natural-language-triggered workflows executing independently) beyond a described 'describe the audience... mParticle suggests logic' feature that is marketing copy without technical detail. missing for 10: technical documentation of autonomous/agentic triggers, evidence of AI-driven automation execution (not just audience/segment sync), independent corroboration of these automations running reliably in production.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”

   proof ↗⚑ flag

   Hightouch✓fullclaimed7/10

   Hightouch supports scheduled/triggered syncs and automated journeys that run continuously without manual intervention, plus AI Decisioning that uses reinforcement learning to autonomously choose message/channel/timing and measure outcomes, and CDC-based background data propagation — all core 'set it and forget it' automations. missing for 10: no evidence of autonomous multi-step agentic workflows beyond marketing ops (e.g., self-initiated remediation, cross-tool agent chains) and no independent hands-on confirmation of long-running autonomous behavior.

   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “AI Decisioning uses reinforcement learning to recommend the best message, channel, and timing for each customer, then measures what worked.”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”
   • [claimed-docs] “Instead of sending the full query result on every run, CDC compares the current results to the previous run and only sends new, changed, and…”
   • [claimed-docs] “For higher performance at scale, you can enable the Lightning sync engine to compute CDC directly in the warehouse.”
   • [claimed-docs] “Get notified when a run fails [Configure sync alerts]”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Hightouch
   mParticle~partialclaimed3/10

   mParticle marketing mentions a natural-language feature where a user can 'describe the audience, journey, or growth goal' and mParticle suggests logic to activate it, which is a narrow AI-assisted capability rather than a general-purpose built-in assistant for delegating tasks. Missing for 10: evidence of a general-purpose conversational assistant, documentation of its scope/capabilities beyond audience building, and any independent/hands-on corroboration of it working.

   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

   Hightouch~partialclaimed5/10

   Docs explicitly mention a 'built-in agent' for exploring segments and analyzing campaign performance in natural language (hightouch-docs-19), and AI Decisioning uses reinforcement learning as an automated in-product agent (hightouch-docs-14). However, most of the detailed AI-assistant documentation (hightouch-docs-10/11/12/31, probe-4) actually describes the MCP server letting external AI assistants control Hightouch, not a dedicated in-app assistant UI with its own docs page. Missing for 10: a dedicated feature page describing the built-in assistant's UI/workflow, independent hands-on reports of using it, and detail on its scope/limitations.

   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “AI Decisioning uses reinforcement learning to recommend the best message, channel, and timing for each customer, then measures what worked.”
   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Hightouch
   mParticle~partialclaimed4/10

   Marketing copy claims a natural-language interface for building audiences ('Describe the audience, journey, or growth goal... mParticle understands the customer data behind it, suggests the logic to use'), which is a genuine NL-command capability, but it's scoped only to audience/segment creation rather than general product operation, and is unsupported by technical docs, screenshots, or independent corroboration. Missing for 10: technical documentation of the NL interface, evidence it covers broader product operations beyond audience building, and independent/hands-on verification.

   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

   Hightouch✓fullprobed8/10

   Hightouch documents a first-party MCP server enabling natural-language commands to build audiences, manage syncs, design journeys, and generate creatives (e.g. 'Create an audience... then create a sync to Braze'), plus a built-in in-product agent for exploring segments/analyzing campaigns in natural language. This is corroborated by an llms.txt describing Hightouch as an 'Agentic Marketing Platform' and runtime probes confirming the MCP docs and API exist. Missing for 10: independent/hands-on user reports specifically validating the MCP/agent natural-language workflows (only vendor docs and generic HN commentary on other features exist).

   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [probe] “official MCP server documented at https://hightouch.com/docs/ai-integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   mParticle—none0/10

   The evidence pack lists many docs pages and API references but contains no mention of an interactive API reference with runnable/try-it-now examples (e.g., embedded Swagger/Postman consoles or live code sandboxes). Absence of evidence for this applicable capability yields 'none'.

   ⚑ flag

   Hightouch—none0/10

   Hightouch documents a REST API with auth guidance (hightouch-docs-13, hightouch-docs-33) but there is no evidence of an interactive API reference with runnable examples — probes for openapi.json/swagger.json all returned 404 across every candidate path, and no docs mention a try-it console, Postman collection, or embedded API explorer.

   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hightouch.com/openapi.json, https://hightouch.com/swagger.json, https://hightouch.com/api/op…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   mParticle—none0/10

   The evidence pack documents multiple mParticle APIs (HTTP events API, Warehouse Sync API, Platform Audiences API) but contains no mention of a downloadable OpenAPI/Swagger spec or any machine-readable API definition file. As a platform with extensive APIs, this axis clearly applies, but no evidence shows the capability exists.

   ⚑ flag

   Hightouch—none0/10

   Hightouch has a REST API (hightouch-docs-13, hightouch-probe-rt-1) but explicit probes for an OpenAPI/Swagger spec at all standard paths returned 404 (hightouch-probe-3), and no docs page offers a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://hightouch.com/openapi.json, https://hightouch.com/swagger.json, https://hightouch.com/api/op…”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   mParticle—none0/10

   No evidence pack items mention a sandbox, staging, test environment, or non-production workspace for mParticle; the docs and probes describe production APIs (auth-gated events API) and SDK installation but nothing about isolated test data flows. This is a plausible axis for a CDP platform (workspaces/sandboxes are common), so absence of evidence yields 'none' rather than 'na'. missing for 10: any mention of a sandbox/test workspace, non-production API keys, or a documented way to isolate test events from production data.

   ⚑ flag

   Hightouch—none0/10

   No evidence in the pack of a sandbox/staging environment or test mode that isolates AI-native testing from production data; docs cover syncs, models, identity resolution, MCP, and API auth, but nothing about a non-production sandbox for testing.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   mParticle—none0/10

   The evidence pack shows API references (events API, Warehouse Sync API, Audiences API) but no mention of API versioning scheme or a documented deprecation policy anywhere in the docs or probes. Missing for 10: explicit API version numbers/headers, a published deprecation/sunset policy, changelog or migration guide practices.

   ⚑ flag

   Hightouch—none0/10

   Evidence confirms Hightouch has a REST API (bearer-token auth, resources like syncs/models) but nothing in the docs pack mentions API versioning scheme (e.g., v1/v2) or any documented deprecation policy; OpenAPI spec discovery even failed (404s). missing for 10: any mention of API version numbers, changelog, or deprecation/sunset policy for the REST API or MCP server.

   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hightouch.com/openapi.json, https://hightouch.com/swagger.json, https://hightouch.com/api/op…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”

   proof ↗⚑ flag

Agent audiences

1. ai-native userAn agent can query customer data and create or activate audiences end to end through documented APIs or MCP — no dashboard in the loop

   weight 3 · round to Hightouch
   mParticle~partialclaimed4/10

   mParticle has documented platform APIs for audiences (docs-19), composable audiences (docs-20), and Warehouse Sync API for ingesting/querying data (docs-x4), suggesting some end-to-end audience creation via API is possible. However, mParticle's own docs describe connecting an audience to an activation output as requiring dashboard steps ('Navigate to Data Platform > Setup > Directory, and click the card for your audience partner of choice' — docs-x2), directly contradicting a no-dashboard activation flow, and there is no mention of an MCP server or agent-native interface anywhere in the pack. Missing for 10: an MCP server or agent-tool endpoint, API-only activation (bypassing the documented dashboard step), and any hands-on/independent confirmation of a full agent-driven query-to-activation loop.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”

   proof ↗⚑ flag

   Hightouch✓fullprobed7/10

   Hightouch documents an official MCP server that lets an AI assistant directly create audiences, build syncs to activate them (e.g., to Braze), and even generate creatives — explicitly in natural language with no dashboard step described (hightouch-docs-10/11/12/31, hightouch-probe-4, hightouch-probe-rt-2). This is reinforced by a documented, auth-gated REST API covering syncs/models/sources/destinations (hightouch-docs-13, hightouch-probe-rt-1) for programmatic control beyond MCP. missing for 10: independent/hands-on verification that MCP-driven audience creation works end-to-end without any dashboard dependency, and clarity on whether initial schema/model setup (docs-1/24/35 imply UI-based schema config precedes audience building) can be fully done via MCP/API alone.

   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”
   • [claimed-docs] “Ad Studio Customers: Generate visual ad creatives from a prompt, refine them with follow-up instructions, and browse existing projects.”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [probe] “official MCP server documented at https://hightouch.com/docs/ai-integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”

   proof ↗⚑ flag

Agent pipeline

1. ai-native userAn agent can manage the pipeline itself — create sources and destinations, wire streams, inspect deliveries — through a documented API or MCP server

   weight 3 · round to Hightouch
   mParticle~partialclaimed4/10

   mParticle documents real management APIs (Platform Audiences API, Warehouse Sync API, HTTP events API) and an Integrations directory, so an agent could plausibly automate parts of the pipeline, but the docs explicitly describe connecting an audience to an output as a manual UI action ('Navigate to Data Platform > Setup > Directory, and click the card for your audience partner') rather than an API call, and there is no mention of an MCP server or agent-oriented control plane. Missing for 10: an MCP server, documented API endpoints for creating/wiring destinations and inspecting delivery status, and any hands-on evidence of agent-driven pipeline configuration.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”

   proof ↗⚑ flag

   Hightouch✓fullprobed7/10

   Hightouch documents both an official MCP server (build audiences, manage syncs, design journeys, generate creatives, analyze performance) and a REST API explicitly covering syncs, models, sources, and destinations, plus a live authenticated API endpoint confirmed via probe. This directly satisfies the story of an agent managing the pipeline via API/MCP, including inspecting sync run outcomes/debugging. Missing for 10: explicit MCP-level source/destination creation (MCP docs emphasize audiences/syncs/journeys, not raw source/destination wiring), no discoverable OpenAPI spec, and no independent/hands-on evidence of an agent actually performing end-to-end pipeline management.

   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “A sync connects one model to one destination object, list, or table, and describes how the model's rows map into that destination.”
   • [claimed-docs] “Check a run or debug rejected rows | [Debug a sync run](/docs/syncs/debugger)”
   • [probe] “official MCP server documented at https://hightouch.com/docs/ai-integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”

   proof ↗⚑ flag

Ai assist

1. ai-native userDescribe an audience in natural language and AI builds the segment definition for review, grounded in my actual schema

   weight 2 · round to Hightouch
   mParticle~partialclaimed5/10

   mParticle's marketing copy explicitly promises the described capability ('Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn intent into revenue-driving activation'), matching the natural-language-to-segment-definition story, and Composable Audiences docs show audience definitions are schema-grounded. However, this is only a marketing tagline with no supporting product documentation, UI walkthrough, or independent/hands-on verification of how the AI-generated segment is presented for review or how grounding in the actual schema works. Missing for 10: detailed docs/tutorial on the natural-language audience builder workflow, evidence of a review/edit step before segment creation, and independent or hands-on confirmation that it works as advertised.

   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Audiences”

   proof ↗⚑ flag

   Hightouch✓fullprobed8/10

   Hightouch's MCP server and built-in agent let users describe an audience in natural language (e.g. 'customers who added an item to cart but didn't complete a transaction') and have AI build the segment definition grounded in the actual warehouse schema/models, then present it for review before syncing (hightouch-docs-10, hightouch-docs-11, hightouch-docs-19, hightouch-probe-rt-2). missing for 10: independent/hands-on evidence (beyond vendor docs) confirming accuracy of schema grounding and an explicit UI review/approval step before the audience is finalized.

   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”
   • [probe] “official MCP server documented at https://hightouch.com/docs/ai-integrations/mcp”

   proof ↗⚑ flag

Ai decisioning

1. ai-native userAI decisioning agents pick messages, timing, and channels per customer autonomously within guardrails I set, with measurable lift

   weight 2 · round to Hightouch
   mParticle—none0/10

   mParticle's evidence shows predictive audience scoring and natural-language audience creation (docs-15, docs-16) but nothing describing autonomous agents selecting messages, timing, or channels per customer, nor any measurable lift reporting tied to such decisioning — this is a CDP/audience-activation tool, not a decisioning/orchestration engine.

   • [claimed-docs] “Score likelihood to churn, convert, or grow in value, then activate audiences before risk or opportunity passes.”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

   Hightouch~partialclaimed5/10

   Hightouch documents an 'AI Decisioning' capability that uses reinforcement learning to recommend the best message, channel, and timing per customer and then measures outcomes, directly matching the core of this story. However, evidence is a single thin doc mention with no detail on configurable guardrails, no independent case studies or benchmarks proving measurable lift, and no hands-on validation. Missing for 10: documented guardrail/constraint configuration, quantified lift case studies, independent or customer corroboration of decisioning performance.

   • [claimed-docs] “AI Decisioning uses reinforcement learning to recommend the best message, channel, and timing for each customer, then measures what worked.”
   • [claimed-docs] “Set up permissions, approvals, and ownership boundaries so each team has the right level of access.”

   proof ↗⚑ flag

Activation

1. marketerAudiences sync to ad platforms and engagement tools continuously, with membership entering and exiting in near-real-time

   weight 2 · round drawn
   mParticle~partialclaimed6/10

   mParticle's Audiences and Composable Audiences docs describe building audiences and connecting them to activation outputs (ad platforms, marketing tools) via one-click integrations, and Composable Audiences is positioned for near-real-time segment updates from warehouse data. However, the evidence doesn't explicitly confirm continuous/near-real-time sync cadence for entry/exit membership across all outputs, nor independent confirmation of sync latency in production. missing for 10: documented sync frequency/latency guarantees, independent/hands-on confirmation of near-real-time membership updates propagating to ad platforms, and clarity on which outputs support continuous vs batch sync.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Grow undersized or saturated audiences from your strongest customer behaviors, increasing addressable reach without defaulting to broad targ…”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Hightouch supports syncing audiences to ad platforms/engagement tools on a schedule or trigger with CDC to only send new/changed/removed rows, which supports near-real-time membership changes, but syncs are still schedule/trigger-based batch jobs rather than a documented continuous streaming/real-time audience membership pipeline. missing for 10: explicit documentation of true real-time/streaming sync latency (e.g. sub-minute or event-triggered entry/exit), independent evidence of sync frequency/latency in production, and confirmation that ad platform destinations support such near-real-time updates rather than periodic batch syncs.

   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “Instead of sending the full query result on every run, CDC compares the current results to the previous run and only sends new, changed, and…”
   • [claimed-docs] “For higher performance at scale, you can enable the Lightning sync engine to compute CDC directly in the warehouse.”
   • [claimed-docs] “A sync connects one model to one destination object, list, or table, and describes how the model's rows map into that destination.”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”

   proof ↗⚑ flag

Audiences

1. marketerBuild audiences from traits and behavior in a visual builder — no SQL required — and see estimated size before activating

   weight 3 · round to Hightouch
   mParticle~partialclaimed3/10

   Docs confirm audience segmentation and 'Composable Audiences' functionality exists (mparticle-docs-19, mparticle-docs-20, mparticle-docs-7) and audiences can be connected to activation outputs (mparticle-docs-x2), but nothing describes a no-SQL visual builder UI or an estimated-audience-size preview before activation. missing for 10: explicit evidence of a drag-and-drop/visual audience builder interface, confirmation that no SQL is required, and any feature showing estimated audience size prior to activation.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Engage customer cohorts”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Docs confirm a no-code visual builder for audiences (Customer Studio) built on traits/behavior data, explicitly requiring no SQL from marketers, and models can also be built visually per hightouch-docs-23. However, none of the evidence mentions an audience size estimate/preview before activation. Missing for 10: explicit documentation or screenshot of estimated audience size display prior to activating a sync, and independent/hands-on confirmation of the visual builder UX.

   • [claimed-docs] “marketers can build audiences and journeys in a no-code UI. Audiences cannot be created until this step is complete.”
   • [claimed-docs] “Once the schema is configured, marketers can build audiences and journeys in a no-code UI.”
   • [claimed-docs] “Once the schema is configured, marketers can build [audiences](/docs/customer-studio/usage) and [journeys](/docs/customer-studio/journeys) i…”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “Models — Define reusable datasets with SQL, dbt, or a visual builder”

   proof ↗⚑ flag

Traits

1. marketerComputed traits and predictive scores (LTV, churn or purchase propensity) are calculated on profiles and usable in targeting

   weight 2 · round drawn
   mParticle~partialclaimed5/10

   mParticle's marketing pages explicitly claim scoring of churn/conversion/value ('Score likelihood to churn, convert, or grow in value, then activate audiences') and growing audiences from strongest behaviors, and Composable Audiences/Audiences API docs show how such traits could be used for targeting, but there is no first-party technical documentation describing how LTV/churn/propensity scores are computed, no worked example of a score becoming a usable trait, and no independent or hands-on corroboration. missing for 10: technical docs on the predictive-scoring model/methodology, a concrete example of a computed trait/score feeding an audience, and independent verification that these scores work as advertised.

   • [claimed-docs] “Score likelihood to churn, convert, or grow in value, then activate audiences before risk or opportunity passes.”
   • [claimed-docs] “Grow undersized or saturated audiences from your strongest customer behaviors, increasing addressable reach without defaulting to broad targ…”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

   Hightouch~partialclaimed5/10

   Hightouch clearly supports computed traits: models can be built with SQL, dbt, or a visual builder and used directly in audience/journey targeting via Customer Studio, and Identity Resolution can produce a golden-record profile view. However, there is no evidence of a native predictive-scoring capability (LTV, churn, purchase propensity) computed by Hightouch itself — the closest feature, 'AI Decisioning,' is a reinforcement-learning message/channel/timing optimizer, not a per-profile predictive score usable as an audience filter attribute. Missing for 10: documentation of built-in ML models producing LTV/churn/propensity scores stored as profile attributes, and evidence these specific score types are selectable in audience-builder filters.

   • [claimed-docs] “Models — Define reusable datasets with SQL, dbt, or a visual builder”
   • [claimed-docs] “Data teams typically create models by writing SQL in the editor, selecting from tables or views, or re-using dbt models and BI queries from …”
   • [claimed-docs] “Identity Resolution links related customer records into unified identities in your warehouse, so every downstream product works from one con…”
   • [claimed-docs] “Golden Record — a one-row-per-identity table of canonical field values (selected by survivorship rules) that many teams use as their source-…”
   • [claimed-docs] “AI Decisioning uses reinforcement learning to recommend the best message, channel, and timing for each customer, then measures what worked.”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “Once the schema is configured, marketers can build audiences and journeys in a no-code UI.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Hightouch
   mParticle~partialclaimed5/10

   mParticle's Warehouse Sync API and Platform APIs (Audiences, Consent Filters, Data Privacy Controls) support bulk data ingestion and management across many users/events, which is the closest evidence to bulk operations, but there is no explicit documentation of a batch/bulk event API, rate limits, or multi-item CRUD operations tailored for programmatic/AI-native bulk use. Missing for 10: explicit bulk/batch endpoint documentation, batch size limits, and examples of bulk create/update/delete operations across items (e.g., audiences, users, events) in a single call.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Hightouch's core sync engine operates on whole models/audiences (bulk rows) on each run, and the platform explicitly supports batch event ingestion ("Use the batch endpoint to submit multiple events... in a single request") plus a REST API for programmatically managing syncs, models, sources, and destinations. However, evidence doesn't show explicit bulk-management API operations (e.g., batch-update many syncs/audiences in one call) — it only shows single-resource CRUD and batch data ingestion. Missing for 10: explicit bulk/batch API operations across multiple resources at once (not just event ingestion), and independent verification of large-scale bulk sync performance.

   • [claimed-docs] “Use the batch endpoint to submit multiple events to the collector in a single request.”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “A sync connects one model to one destination object, list, or table, and describes how the model's rows map into that destination.”
   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “Git Sync lets you manage workspace resources programmatically.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Hightouch
   mParticle~partialclaimed5/10

   mParticle supports conditional forwarding rules (e.g., 'do not forward if CCPA opt-out present') and audience-to-output connections that activate when audience membership criteria are met, which are rule-like automations triggered by data events. However, there's no evidence of a general-purpose rule/workflow engine for arbitrary event-triggered actions beyond consent-based forwarding and audience activation. Missing for 10: a documented general automation/rules engine (if-this-then-that style), evidence of custom action triggers beyond forwarding/audience activation, and independent confirmation of this capability working in practice.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Hightouch supports event-driven syncs (trigger on data change/CDC), sync alerts on failure, and journeys that react to customer behavior, which cover rule-based automation of actions on events; however these are framed around marketing/data-sync workflows rather than general-purpose event-condition-action rule definition for arbitrary AI-native automations. missing for 10: a documented general rules/conditions engine (if-this-then-that style) independent of syncs/journeys, evidence of arbitrary event types triggering arbitrary actions beyond syncing/audience creation, and independent/hands-on confirmation of trigger-based automation working reliably.

   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”
   • [claimed-docs] “Get notified when a run fails [Configure sync alerts]”
   • [claimed-docs] “Instead of sending the full query result on every run, CDC compares the current results to the previous run and only sends new, changed, and…”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Hightouch
   mParticle—none0/10

   The evidence pack covers event ingestion, identity resolution, audiences, warehouse sync, and privacy controls, but nothing describes scheduling recurring jobs, workflows, or automated cadences (e.g., cron-like triggers for audience refresh or warehouse sync jobs) that an AI-native user could configure or invoke.

   ⚑ flag

   Hightouch✓fullprobed7/10

   Hightouch syncs run on a defined schedule or trigger and can sync on a cadence or when data changes, and journeys can be built as automated workflows; the MCP server lets an AI assistant manage syncs (which include their schedules) and journeys in natural language. Missing for 10: an explicit worked example of an AI assistant creating or modifying a sync schedule via MCP/natural language (only audience/sync creation and ad generation are shown), and independent confirmation of AI-driven scheduling in practice.

   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”
   • [probe] “PROBE runtime (recorded 2026-09-08): hightouch.com publishes an agent-oriented llms.txt on its main origin ('# Hightouch — Hightouch is an A…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Hightouch
   mParticle—none0/10

   No evidence in the pack discusses versioning, review workflows, or rollback of automations, audiences, or data pipelines; evidence covers event ingestion, identity resolution, audiences, integrations, and compliance controls only. This is a fair axis for a CDP with audience/workflow automation, but nothing shows version history, review/approval, or rollback capability.

   ⚑ flag

   Hightouch~partialcommunity5/10

   Hightouch's Git Sync lets teams manage workspace resources (models, syncs, audiences) programmatically via git, and the platform separately supports approvals/ownership boundaries for review workflows, with a community comparison confirming 'git version control' as a differentiator. However, there is no explicit documentation of a rollback mechanism, version history UI, or how git-based changes propagate back to rollback a live automation. Missing for 10: explicit rollback/restore documentation, versioned change history in the UI, and independent confirmation that Git Sync supports full revert workflows for automations.

   • [claimed-docs] “Git Sync lets you manage workspace resources programmatically.”
   • [claimed-docs] “Set up permissions, approvals, and ownership boundaries so each team has the right level of access.”
   • [community] “Hightouch vs Census comparison from the company: Hightouch offers more developer-focused features (live debugger, alerting, git version cont…”

   proof ↗⚑ flag

Destinations

1. data engineerRoute events to a large catalog of documented destination integrations with per-destination mapping and filtering

   weight 3 · round to Hightouch
   mParticle~partialcommunity7/10

   mParticle documents an integrations directory ('Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks') and shows how to connect audience outputs via the Directory, plus per-destination filtering via Consent Filters and Data Privacy Controls forwarding rules (e.g., 'Do not forward if CCPA Data sale opt out is present'). Community testimony corroborates real-world fan-out to '10 other analytics providers'. However, evidence lacks a documented catalog size/list of destinations or explicit per-destination field-mapping documentation beyond Warehouse Sync's mapping guide. Missing for 10: a documented catalog count/list of destination integrations, and detailed per-destination event/field mapping docs beyond warehouse ingestion.

   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Consent Filters”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [community] “Now we have mParticle, so we can send data only to mParticle and then send it onwards to possibly 10 other analytics providers... Almost the…”

   proof ↗⚑ flag

   Hightouch✓fullcommunity7/10

   Hightouch's docs describe syncs that map one model to a destination object/list/table with per-destination field mapping, unlimited destination counts, scheduled/CDC-based delivery, and run-level debugging, and a HN co-founder interview independently confirms declarative field mapping plus a claim of 70+ deep integrations with visual audience filtering versus competitors. Missing for 10: a public, browsable catalog page listing/counting all supported destinations, and detailed docs on per-destination filtering syntax beyond audience-level filtering.

   • [claimed-docs] “A sync connects one model to one destination object, list, or table, and describes how the model's rows map into that destination.”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”
   • [claimed-docs] “Up to 2 active syncs * Unlimited destination count * Unlimited user seats”
   • [claimed-docs] “Instead of sending the full query result on every run, CDC compares the current results to the previous run and only sends new, changed, and…”
   • [claimed-docs] “Get notified when a run fails [Configure sync alerts]”
   • [community] “Hightouch cofounder explained syncs are declarative: you define a SQL model, and Hightouch figures out how to map it to the destination (e.g…”
   • [community] “Hightouch vs Census comparison from the company: Hightouch offers more developer-focused features (live debugger, alerting, git version cont…”

   proof ↗⚑ flag

Ingest

1. data engineerSend events server-to-server through a documented HTTP ingestion API with authentication and delivery guarantees

   weight 2 · round drawn
   mParticle~partialprobed6/10

   mParticle documents a server-to-server HTTP events API ("Send events directly to mParticle") and a live probe confirms it is auth-gated (401 without keys), matching documented key/secret basic auth - directly supporting server-to-server ingestion with authentication. Missing for 10: explicit documentation of delivery guarantees (retry semantics, at-least-once delivery, batching/queueing behavior) for the endpoint, and independent non-vendor confirmation of reliability under load.

   • [claimed-docs] “Send events directly to mParticle”
   • [claimed-docs] “Send your first event to mParticle”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Hightouch documents an HTTP Tracking API for server-to-server event ingestion, including a batch endpoint and defined event types (identify, track, page, screen, group), which lands in the customer's warehouse. However, the evidence does not explicitly document authentication requirements or delivery guarantees (retries, idempotency, at-least-once semantics) specifically for this Events API — the bearer-token auth and run-level failure alerts/debugging described elsewhere apply to the general REST API and sync pipeline, not confirmed for the events collector itself. missing for 10: explicit auth mechanism for the HTTP Tracking/Events API, documented delivery/retry guarantees or acknowledgement semantics for event ingestion, and independent confirmation of reliability at scale.

   • [claimed-docs] “Hightouch provides SDKs for browser, iOS, Android, Node.js, and other platforms, plus an HTTP API for server-side ingestion”
   • [claimed-docs] “Hightouch's HTTP Tracking API enables you to record data from any website or application.”
   • [claimed-docs] “Hightouch provides SDKs for [browser](/docs/events/sdks/browser), [iOS](/docs/events/sdks/ios), [Android](/docs/events/sdks/android), [Node.…”
   • [claimed-docs] “Use the batch endpoint to submit multiple events to the collector in a single request.”
   • [claimed-docs] “Events come in five types — identify, track, page, screen, and group — each for a different kind of action.”
   • [claimed-docs] “You instrument your app, site, or backend with a Hightouch SDK, the HTTP API, or a streaming source like Kafka or Google Pub/Sub.”
   • [claimed-docs] “Authenticate each request by passing your API key as a bearer token in the `Authorization` header”

   proof ↗⚑ flag

Sdks

1. data engineerCollect events from web, mobile, and server apps through official SDKs that implement a documented tracking spec (track, identify, page)

   weight 3 · round to Hightouch
   mParticle~partialprobed7/10

   mParticle documents client SDKs, a server-to-server events API, and event-sending guides, and a runtime probe confirms the API is live and the web SDK installs and exports init — covering web, mobile, and server ingestion paths. However, the evidence never explicitly names a documented spec of track/identify/page-style methods (only generic 'send your first event' and IDSync identity docs), so full parity with that canonical spec isn't shown. Missing for 10: explicit SDK method documentation for track/identify/page calls, and independent hands-on confirmation across mobile SDKs specifically.

   • [claimed-docs] “Send your first event to mParticle”
   • [claimed-docs] “Send events directly to mParticle”
   • [claimed-docs] “Client SDKs”
   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch✓fullclaimed8/10

   Hightouch Events documents official SDKs for browser, iOS, Android, and Node.js plus an HTTP API/batch endpoint for server-side ingestion, and explicitly defines a tracking spec with five event types (identify, track, page, screen, group), matching the story's core ask. missing for 10: independent/hands-on developer corroboration that the SDKs work as documented in production, and no visible changelog/version history proving spec stability over time.

   • [claimed-docs] “Hightouch Events collects customer behavior from websites, mobile apps, and backend systems, then stores that data in your warehouse.”
   • [claimed-docs] “Hightouch provides SDKs for browser, iOS, Android, Node.js, and other platforms, plus an HTTP API for server-side ingestion”
   • [claimed-docs] “Hightouch's HTTP Tracking API enables you to record data from any website or application.”
   • [claimed-docs] “Events come in five types — identify, track, page, screen, and group — each for a different kind of action.”
   • [claimed-docs] “Hightouch provides SDKs for [browser](/docs/events/sdks/browser), [iOS](/docs/events/sdks/ios), [Android](/docs/events/sdks/android), [Node.…”
   • [claimed-docs] “Use the batch endpoint to submit multiple events to the collector in a single request.”
   • [claimed-docs] “You instrument your app, site, or backend with a Hightouch SDK, the HTTP API, or a streaming source like Kafka or Google Pub/Sub.”

   proof ↗⚑ flag

Sources

1. data engineerPull customer data in from third-party cloud apps and feeds — not just my own instrumented apps

   weight 1 · round to mParticle
   mParticle~partialprobed7/10

   mParticle's Warehouse Sync API explicitly ingests data from third-party cloud warehouses (Snowflake, Redshift, BigQuery, Databricks) into mParticle, and its Integrations directory implies broad connectivity beyond self-instrumented apps, with the runtime probe confirming the events/API endpoints are live and auth-gated. However, evidence is warehouse-centric rather than showing inbound feeds from other cloud apps (e.g., CRM, ad platforms, SaaS tools) as data sources. Missing for 10: documented inbound 'feeds' from non-warehouse SaaS/cloud apps, and independent/hands-on confirmation of Warehouse Sync working end-to-end.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch—none0/10

   Hightouch's evidence describes a reverse-ETL/composable-CDP architecture: models are read FROM the warehouse and synced OUT to destinations (docs-2, docs-20, docs-27), and its only inbound 'ingestion' feature (Hightouch Events) explicitly covers only the customer's own instrumented websites/apps/backends via SDKs or HTTP API (docs-5, docs-6, docs-41) — the exact case the story excludes. There is no documented source connector for pulling data in from third-party cloud apps/feeds (e.g., Salesforce, Stripe, Zendesk) into the warehouse; 'sources' in the API refer to warehouses, not external SaaS ingestion.

   • [claimed-docs] “Data teams typically create models by writing SQL in the editor, selecting from tables or views, or re-using dbt models and BI queries from …”
   • [claimed-docs] “Hightouch Events collects customer behavior from websites, mobile apps, and backend systems, then stores that data in your warehouse.”
   • [claimed-docs] “Hightouch provides SDKs for browser, iOS, Android, Node.js, and other platforms, plus an HTTP API for server-side ingestion”
   • [claimed-docs] “You instrument your app, site, or backend with a Hightouch SDK, the HTTP API, or a streaming source like Kafka or Google Pub/Sub.”
   • [claimed-docs] “A sync connects one model to one destination object, list, or table, and describes how the model's rows map into that destination.”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”

   proof ↗⚑ flag

Profiles

1. data engineerQuery unified customer profiles — traits, identifiers, event history — through a documented profile API or store

   weight 2 · round drawn
   mParticle~partialclaimed6/10

   mParticle documents IDSync as the identity-resolution framework producing a unified customer view (mparticle-docs-x1, docs-9), a 'Real-time API to drive user personalization' (docs-4) that implies profile querying, and a Warehouse Sync API/store that syncs mParticle data (including profiles) into Snowflake/Redshift/BigQuery/Databricks (mparticle-docs-x4, docs-18), giving a documented store-based path to unified profile data. However, no evidence pack item shows a concrete 'Profile API' schema or example query returning traits/identifiers/event history in one documented endpoint, so the specific query mechanics remain unconfirmed. Missing for 10: explicit Profile API reference docs with request/response schema, hands-on example querying traits+identifiers+event history together, independent developer corroboration of the API's completeness.

   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [claimed-docs] “Real-time API to drive user personalization”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Get a complete view of your users”

   proof ↗⚑ flag

   Hightouch~partialprobed6/10

   Hightouch's Identity Resolution builds a warehouse-resident Golden Record (traits, canonical identifiers) that docs explicitly say teams can 'query directly' or build models on (hightouch-docs-9, hightouch-docs-43), and its hybrid architecture keeps all profile data in the customer's own warehouse/store rather than a proprietary store (hightouch-comm-3). However, this satisfies the 'store' half of the story via SQL access to warehouse tables rather than a dedicated, documented Profile API for identifier/trait/event lookups — the REST API documented (hightouch-docs-13, hightouch-probe-rt-1) covers syncs/models/sources/destinations management, not profile/event retrieval by customer ID. Missing for 10: a first-party 'Profile API' endpoint (e.g., lookup-by-identifier returning traits+event history), explicit event-history query capability via API, and independent/hands-on confirmation of querying golden-record data through an API rather than raw SQL.

   • [claimed-docs] “Identity Resolution links related customer records into unified identities in your warehouse, so every downstream product works from one con…”
   • [claimed-docs] “Golden Record — a one-row-per-identity table of canonical field values (selected by survivorship rules) that many teams use as their source-…”
   • [claimed-docs] “Query these directly, build models on them in Customer Studio, or sync them downstream.”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [community] “Hightouch's hybrid architecture stores no data in Hightouch itself out of the box—it all stays in the customer's own warehouse/S3 bucket—whi…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”

   proof ↗⚑ flag

Stitching

1. data engineerAnonymous and known activity stitches into one customer profile across devices, with documented and configurable identity-resolution rules

   weight 3 · round to mParticle
   mParticle✓fullclaimed8/10

   mParticle documents IDSync explicitly as its identity-resolution framework for unifying known and anonymous user identities across apps/devices, with dedicated docs on managing identities, data quality enforcement, and a 'complete view of users' guide, indicating configurable identity rules are a first-party, documented capability. Missing for 10: independent/hands-on validation of identity-stitching configuration rules in practice and detail on rule customization options beyond doc titles.

   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [claimed-docs] “Manage user identities with IDSync”
   • [claimed-docs] “Get a complete view of your users”
   • [claimed-docs] “View and enforce your data quality”

   proof ↗⚑ flag

   Hightouch~partialclaimed6/10

   Hightouch documents Identity Resolution linking cross-device/channel signals into a unified identity with a Golden Record built via survivorship rules, and describes unifying data across sources — directly addressing stitching known/anonymous activity into one profile. However, the docs shown don't detail configurable matching rules (e.g., deterministic vs probabilistic matching logic, field-level match keys) beyond survivorship for golden records, and there's no independent/hands-on validation of identity-resolution accuracy. Missing for 10: documentation of specific configurable match-rule types (deterministic/probabilistic, custom match keys), worked examples of anonymous-to-known stitching, and independent verification of resolution quality.

   • [claimed-docs] “Identity Resolution links related customer records into unified identities in your warehouse, so every downstream product works from one con…”
   • [claimed-docs] “Golden Record — a one-row-per-identity table of canonical field values (selected by survivorship rules) that many teams use as their source-…”
   • [claimed-docs] “Resolve identities across devices and channels so teams can build on a more complete customer record.”
   • [claimed-docs] “Unify customer or account data across multiple sources”
   • [claimed-docs] “Identity Resolution links these signals together so related records are treated as a single identity.”
   • [claimed-docs] “Query these directly, build models on them in Customer Studio, or sync them downstream.”
   • [claimed-docs] “If you're coming from a tool that stored and served customer profiles for you, this is the largest shift to plan for. The logic that lived i…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Hightouch
   mParticle~partialprobed5/10

   mParticle exposes substantial API surface for core CDP workflows: event ingestion (events API), Warehouse Sync API, Audiences API, platform APIs, and IDSync are all documented and a probe confirms the events API is live and auth-gated. However, several UI-driven capabilities (data quality enforcement/dashboards, consent filter configuration, audience-output connection wizard, data privacy control panels) are described only as UI/dashboard flows in docs without clear evidence of full parity via API. missing for 10: explicit API coverage for data quality management UI, consent filter/privacy control configuration via API, audience-to-output connection via API rather than UI directory clicks, and independent confirmation that all UI actions have API equivalents.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

   Hightouch~partialprobed6/10

   Hightouch documents a real REST API covering syncs, models, sources, and destinations (hightouch-docs-13, hightouch-probe-rt-1) and a separate MCP server that lets an AI assistant build audiences, journeys, syncs, and creatives in natural language (hightouch-docs-10/11/12, hightouch-probe-4). However, core UI-only features like audience/journey building are explicitly described as done in a 'no-code UI' (hightouch-docs-1/24/35), and the plain REST API guide never lists audience or journey endpoints, only syncs/models/sources/destinations — so parity between UI and raw API is not fully documented; the MCP path partially closes this gap but is a distinct conversational layer, not the generic API. Missing for 10: explicit REST API endpoints for audience/journey creation, and confirmation that MCP/API actions cover 100% of UI capabilities (e.g., Ad Studio, AI Decisioning) rather than a subset.

   • [claimed-docs] “marketers can build audiences and journeys in a no-code UI. Audiences cannot be created until this step is complete.”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”
   • [claimed-docs] “the Hightouch MCP server connects your AI assistant directly to your marketing stack so your team can build audiences, manage syncs, design …”
   • [claimed-docs] “"Create an audience of customers that added an item to their cart in the last day but haven't completed a transaction, then create a sync to…”
   • [claimed-docs] “Once the schema is configured, marketers can build audiences and journeys in a no-code UI.”
   • [probe] “official MCP server documented at https://hightouch.com/docs/ai-integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Hightouch's REST API is live and cleanly auth-gated — a keyless GET https://api.hightouch.com/api/v1/sy…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Hightouch
   mParticle—none0/10

   mParticle documents APIs for sending data in and forwarding it to partner integrations (docs-11, docs-x2) and a Warehouse Sync feature, but the evidence shows Warehouse Sync only ingests data from a customer's warehouse into mParticle (docs-x4), not a comprehensive open-format export/backup of all stored customer data for leaving the platform. No evidence pack item documents a full data-export or account-portability mechanism.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”

   proof ↗⚑ flag

   Hightouch~partialcommunity5/10

   Hightouch's hybrid architecture keeps customer data in the user's own warehouse/S3 by default rather than inside Hightouch (hightouch-comm-3), which means the underlying data is inherently in open, customer-controlled formats and not locked in. Git Sync and the REST API also let workspace resources (models, syncs) be managed/exported programmatically (hightouch-docs-32, hightouch-docs-13). Missing for 10: explicit first-party documentation of a full data export flow/format, no dedicated 'export and leave' guide, and this evidence comes mainly from a community HN thread rather than official docs.

   • [community] “Hightouch's hybrid architecture stores no data in Hightouch itself out of the box—it all stays in the customer's own warehouse/S3 bucket—whi…”
   • [claimed-docs] “Git Sync lets you manage workspace resources programmatically.”
   • [claimed-docs] “Hightouch exposes a REST API that lets users interact with resources like syncs, models, sources, and destinations.”

   proof ↗⚑ flag

Observability

1. data engineerWatch events flow live and diagnose delivery failures per destination — debugger views, delivery metrics, and alerting

   weight 2 · round to Hightouch
   mParticle—none0/10

   The evidence pack lists mParticle's data-quality docs and various integration/audience features but contains no mention of a live event debugger, per-destination delivery metrics, or alerting — the specific observability tooling the story asks for is absent from docs or community evidence.

   • [claimed-docs] “View and enforce your data quality”

   proof ↗⚑ flag

   Hightouch~partialcommunity6/10

   Hightouch's docs confirm a sync-run debugger for checking runs and debugging rejected rows, plus configurable alerts when a run fails, and community evidence (comm-5) explicitly calls out 'live debugger, alerting' as differentiating developer-facing features versus competitors. However, there is no direct evidence of a live event-stream view (watching events flow in real time) or per-destination delivery metrics dashboards beyond the sync debugger and alerting. Missing for 10: live event flow visualization, per-destination delivery metrics/dashboards, and independent hands-on confirmation of debugger usability at scale.

   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “Check a run or debug rejected rows | Debug a sync run”
   • [claimed-docs] “Get notified when a run fails [Configure sync alerts]”
   • [claimed-docs] “Check a run or debug rejected rows | [Debug a sync run](/docs/syncs/debugger)”
   • [community] “Hightouch vs Census comparison from the company: Hightouch offers more developer-focused features (live debugger, alerting, git version cont…”

   proof ↗⚑ flag

Consent

1. privacy leadUser consent is captured and enforced across destinations — opt-outs and consent categories are honored downstream automatically

   weight 3 · round to mParticle
   mParticle✓fullclaimed8/10

   mParticle's Data Privacy Controls docs describe consent state (GDPR and CCPA opt-out) that can be attached to forwarding rules to block data flow to specific downstream destinations, and dedicated Consent Filters and compliance docs reinforce this as a first-class capability. Missing for 10: independent/hands-on validation that opt-outs are actually honored end-to-end across real destination partners, and detail on default vs opt-in enforcement per integration.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Consent Filters”
   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”

   proof ↗⚑ flag

   Hightouch—none0/10

   No evidence pack items mention consent management, opt-outs, consent categories, or any suppression/enforcement mechanism honored across destinations; Hightouch's docs focus on syncs, audiences, identity resolution, and events, none of which describe consent capture or enforcement.

   ⚑ flag

Deletion

1. privacy leadProcess user deletion and suppression requests (GDPR/CCPA) and have them forwarded to connected destinations

   weight 2 · round to mParticle
   mParticle~partialclaimed6/10

   mParticle documents GDPR/CCPA compliance tooling — consent state management, consent filters, and forwarding rules like 'do not forward if CCPA data sale opt-out is present' — which supports suppression enforcement to downstream destinations. However, the evidence never explicitly names a Data Subject Request/deletion API workflow that processes and forwards actual user deletion requests to connected destinations, only consent-based suppression filtering. Missing for 10: explicit documentation of a deletion/erasure request workflow (not just opt-out/consent suppression), and independent confirmation that deletion requests actually propagate to third-party destinations.

   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Consent Filters”

   proof ↗⚑ flag

   Hightouch—none0/10

   The evidence pack describes Hightouch's audience-building, sync, identity resolution, and events capabilities, but contains no mention of deletion/suppression request workflows, DSAR/GDPR-CCPA processing, or forwarding erasure requests to destinations. This is a plausible capability for a CDP/reverse-ETL platform, so the axis applies, but no evidence supports it.

   ⚑ flag

Pii controls

1. privacy leadControl PII flow per destination — hashing, masking, and field-level filtering of sensitive attributes

   weight 2 · round to mParticle
   mParticle~partialclaimed5/10

   mParticle documents Data Privacy Controls with consent-based forwarding rules per destination (e.g., block forwarding to a partner if CCPA opt-out is present) and a general data transformation layer ('Transform data as it enters and leaves mParticle'), which together enable some per-destination control over sensitive data flow. However, there is no direct documentation shown for field-level hashing, masking, or granular PII filtering of specific attributes per destination — the evidence covers consent gating and generic transformation, not explicit hash/mask controls. Missing for 10: explicit field-level hashing/masking docs, granular attribute-level filtering examples, and independent/hands-on confirmation of these controls in practice.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Transform data as it enters and leaves mParticle”
   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”
   • [claimed-docs] “Consent Filters”

   proof ↗⚑ flag

   Hightouch—none0/10

   The evidence pack covers Hightouch's sync engine, identity resolution, events, and permissions/RBAC (docs-34), but nowhere documents field-level hashing, masking, or PII-specific filtering controls scoped per destination. Since Hightouch moves warehouse data (including PII) to many destinations, this is a fair and plausible axis for a reverse-ETL/CDP product, but no capability is evidenced.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Hightouch
   mParticle—none0/10

   The evidence pack covers GDPR/CCPA consent controls and data privacy tooling but contains no mention of selectable data storage regions, data residency zones, or geographic hosting options. This is a fair axis for a CDP handling customer data, but no evidence supports it.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”

   proof ↗⚑ flag

   Hightouch~partialcommunity5/10

   Hightouch's hybrid architecture stores no customer data in Hightouch itself—data stays in the customer's own warehouse/S3 bucket—which gives users effective control over where their data resides by choosing their own warehouse's region, and this underpins its use by regulated fintech/healthcare customers. However, there is no explicit documentation of a region-selection setting or residency options within Hightouch's own platform/control plane. Missing for 10: explicit region/residency configuration UI or docs, statements about where Hightouch's own metadata/control plane is hosted, and any multi-region deployment options.

   • [community] “Hightouch's hybrid architecture stores no data in Hightouch itself out of the box—it all stays in the customer's own warehouse/S3 bucket—whi…”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to mParticle
   mParticle~partialclaimed4/10

   mParticle documents GDPR/CCPA compliance and Data Privacy Controls (consent state, opt-out forwarding rules) which imply some data-governance capability, but the evidence pack never shows explicit retention-period settings or a documented deletion/right-to-be-forgotten API/workflow. Missing for 10: explicit data retention configuration docs, explicit deletion/erasure API or workflow, independent confirmation of deletion behavior.

   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”

   proof ↗⚑ flag

   Hightouch—none0/10

   The evidence pack has no documentation of data retention policies, deletion APIs, or AI-specific data lifecycle controls; the closest tangential fact is that Hightouch doesn't store customer data itself (hightouch-comm-3), but this doesn't describe any deletion/retention control mechanism for AI-native users.

   • [community] “Hightouch's hybrid architecture stores no data in Hightouch itself out of the box—it all stays in the customer's own warehouse/S3 bucket—whi…”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   mParticle—none0/10

   The evidence describes mParticle's consent/privacy features for its customers' end-user data (GDPR/CCPA opt-out, consent filters) but contains no mention of an AI-native user opting out of mParticle's own product telemetry or usage tracking of the tool itself.

   ⚑ flag

   Hightouch—none0/10

   No evidence pack content addresses telemetry/usage-tracking opt-out settings for Hightouch itself; all docs concern data sync, identity resolution, and API features unrelated to product telemetry controls.

   ⚑ flag

Replay

1. data engineerReplay archived events into a new destination or backfill history when a tool is added or a pipeline breaks

   weight 2 · round to mParticle
   mParticle~partialclaimed4/10

   mParticle's Warehouse Sync API lets engineers ingest historical data from a data warehouse (Snowflake, Redshift, BigQuery, Databricks) back into mParticle, which could serve as a backfill mechanism when a new destination needs historical data, and new destinations can be connected via the Integrations directory. However, there is no documented dedicated 'replay archived events' feature or explicit backfill-on-destination-add workflow. Missing for 10: explicit event-replay/backfill documentation, retention/archival guarantees for raw events, and confirmation that replayed data forwards correctly to newly added destinations.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Warehouse Sync API Overview”

   proof ↗⚑ flag

   Hightouch—none0/10

   Hightouch's sync docs describe scheduled/triggered syncs, CDC, and run debugging, but there is no evidence of replaying archived events or backfilling historical data into a new destination when a pipeline breaks or a tool is added; Hightouch Events pipes live behavioral events into the warehouse, not archived-event replay. missing for 10: any mention of event/data replay, backfill mechanisms, historical resync into new destinations, or reprocessing archived data after pipeline failure.

   • [claimed-docs] “A sync runs on the schedule or trigger you set, then reports the outcome of each run so you can confirm it worked.”
   • [claimed-docs] “Instead of sending the full query result on every run, CDC compares the current results to the previous run and only sends new, changed, and…”
   • [claimed-docs] “For higher performance at scale, you can enable the Lightning sync engine to compute CDC directly in the warehouse.”
   • [claimed-docs] “Hightouch Events collects customer behavior from websites, mobile apps, and backend systems, then stores that data in your warehouse.”

   proof ↗⚑ flag

Data quality

1. data engineerA tracking plan or schema is enforced — violating events get flagged, blocked, or quarantined instead of silently corrupting downstream data

   weight 2 · round to mParticle
   mParticle~partialclaimed4/10

   mParticle docs reference a data-quality enforcement feature ("View and enforce your data quality"), consistent with tracking-plan enforcement, but the evidence pack gives only a title with no detail on how violating events are flagged, blocked, or quarantined. Missing for 10: documentation of actual blocking/quarantine behavior, plan validation rules, examples of violation handling, and independent confirmation it works as described.

   • [claimed-docs] “View and enforce your data quality”

   proof ↗⚑ flag

   Hightouch—none0/10

   Hightouch's Events feature mentions a 'schema' step and syncs that can flag 'rejected rows' at the destination side, but there is no evidence of tracking-plan validation, blocking, or quarantining of malformed/violating events at ingestion — the debugger references relate to sync/destination failures, not schema enforcement on incoming event data.

   • [claimed-docs] “Once the schema is configured, marketers can build audiences and journeys in a no-code UI.”
   • [claimed-docs] “Once the schema is configured, marketers can build [audiences](/docs/customer-studio/usage) and [journeys](/docs/customer-studio/journeys) i…”
   • [claimed-docs] “Check a run or debug rejected rows | Debug a sync run”
   • [claimed-docs] “Check a run or debug rejected rows | [Debug a sync run](/docs/syncs/debugger)”
   • [claimed-docs] “Events come in five types — identify, track, page, screen, and group — each for a different kind of action.”

   proof ↗⚑ flag

Transformations

1. data engineerTransform, filter, and enrich events in-pipeline with custom code or functions before they reach destinations

   weight 2 · round to Hightouch
   mParticle~partialclaimed4/10

   mParticle documents a 'Transform data as it enters and leaves mParticle' capability, which aligns with in-pipeline transformation before forwarding to destinations, but the evidence pack only shows a title reference with no detail on custom code/function support, filtering logic, or enrichment specifics. missing for 10: documentation of custom code/JS-based transformation authoring, examples of filtering/enrichment logic, and independent/hands-on validation of the transformation feature working as described.

   • [claimed-docs] “Transform data as it enters and leaves mParticle”

   proof ↗⚑ flag

   Hightouch~partialclaimed5/10

   Hightouch lets data engineers define models via SQL, dbt, or a visual builder (docs-2, docs-23), which supports filtering and transforming data before syncing to destinations, and CDC only sends changed rows (docs-25/36). However, there's no evidence of custom code/functions (e.g., JS/Python transform steps) applied in-pipeline for enrichment beyond SQL modeling, nor any dedicated transformation-step API distinct from model definition. Missing for 10: explicit custom-code/function transformation step, enrichment logic beyond SQL/dbt models, and independent verification of such capability.

   • [claimed-docs] “Data teams typically create models by writing SQL in the editor, selecting from tables or views, or re-using dbt models and BI queries from …”
   • [claimed-docs] “Models — Define reusable datasets with SQL, dbt, or a visual builder”
   • [claimed-docs] “Instead of sending the full query result on every run, CDC compares the current results to the previous run and only sends new, changed, and…”
   • [claimed-docs] “CDC compares the current results to the previous run and only sends new, changed, and removed rows.”

   proof ↗⚑ flag

Composable

1. data engineerRun warehouse-native: define models and audiences on tables already in my warehouse and activate them without re-collecting the data (reverse ETL)

   weight 2 · round to Hightouch
   mParticle~partialclaimed4/10

   mParticle ships a documented Warehouse Sync feature (Snowflake, Redshift, BigQuery, Databricks) with a Warehouse Sync API and SQL reference, letting engineers pull warehouse tables into mParticle for audience/profile use [mparticle-docs-x4][mparticle-docs-18]. However this is ingestion, not warehouse-native activation — the docs explicitly describe it as syncing/copying data into mParticle rather than defining models and activating audiences directly on tables in place without re-collection, which is the core of the reverse-ETL/warehouse-native story. Missing for 10: evidence of querying/modeling directly on warehouse tables without copying data into mParticle, and activation flows that bypass ingestion entirely.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”

   proof ↗⚑ flag

   Hightouch✓fullcommunity8/10

   Hightouch's core model is warehouse-native: models are defined via SQL/dbt/BI queries directly on warehouse tables (docs-2, docs-23), audiences/Customer Studio build on top of these warehouse models (docs-19, docs-43), and syncs activate data to destinations on a schedule without re-collecting or storing it elsewhere (docs-20, docs-27, docs-26 CDC computed in-warehouse). Independent community testimony corroborates that syncs are declarative SQL-to-destination mappings and that Hightouch stores no data itself, keeping everything in the customer's own warehouse (hightouch-comm-2, hightouch-comm-3). Missing for 10: independent hands-on performance benchmarks proving no-recollection at scale, and no third-party audit of the 'no data stored' claim beyond company/community anecdote.

   • [claimed-docs] “Data teams typically create models by writing SQL in the editor, selecting from tables or views, or re-using dbt models and BI queries from …”
   • [claimed-docs] “Models — Define reusable datasets with SQL, dbt, or a visual builder”
   • [claimed-docs] “Create audiences from warehouse data, build automated journeys, and use the built-in agent to explore segments and analyze campaign performa…”
   • [claimed-docs] “Sync modeled data to sales, support, analytics, and internal tools on a schedule or when data changes.”
   • [claimed-docs] “A sync connects one model to one destination object, list, or table, and describes how the model's rows map into that destination.”
   • [claimed-docs] “For higher performance at scale, you can enable the Lightning sync engine to compute CDC directly in the warehouse.”
   • [claimed-docs] “Query these directly, build models on them in Customer Studio, or sync them downstream.”
   • [community] “Hightouch cofounder explained syncs are declarative: you define a SQL model, and Hightouch figures out how to map it to the destination (e.g…”
   • [community] “Hightouch's hybrid architecture stores no data in Hightouch itself out of the box—it all stays in the customer's own warehouse/S3 bucket—whi…”

   proof ↗⚑ flag

Warehouse sync

1. data engineerRaw events and profiles land in my own warehouse or lake (Snowflake, BigQuery, ClickHouse, S3) on a schedule I control

   weight 3 · round to Hightouch
   mParticle~partialclaimed4/10

   mParticle's integrations page generically claims connections to 'data warehousing solutions with just a few clicks' (mparticle-docs-11), suggesting some warehouse export capability, but the only detailed warehouse-related feature in evidence — Warehouse Sync — is documented as ingesting data FROM the customer's warehouse INTO mParticle (reverse direction), not exporting raw events/profiles OUT to a warehouse on a schedule the engineer controls (mparticle-docs-x4). No evidence names Snowflake/BigQuery/ClickHouse/S3 as scheduled export destinations for raw events/profiles, and ClickHouse is never mentioned at all. Missing for 10: documented outbound/export pipeline to specific warehouses, schedule/cadence control details, and any hands-on or independent confirmation of export working as claimed.

   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”

   proof ↗⚑ flag

   Hightouch✓fullcommunity7/10

   Hightouch Events explicitly ingests raw behavioral events via SDKs, HTTP API, or streaming sources (Kafka/Pub/Sub) and stores them directly in the customer's own warehouse (Snowflake, BigQuery, etc.), and Identity Resolution builds unified 'golden record' profiles in that same warehouse — confirmed independently by an HN comment noting Hightouch's hybrid architecture stores no data itself, everything stays in the customer's warehouse/S3. Models are built with SQL/dbt directly against warehouse tables, keeping engineers in control of the data layer. missing for 10: explicit documentation of a configurable ingestion schedule/cadence for raw event landing (docs mostly describe real-time streaming ingestion, not a data-engineer-set batch schedule), and independent hands-on validation of warehouse-landing reliability at scale.

   • [claimed-docs] “Hightouch Events collects customer behavior from websites, mobile apps, and backend systems, then stores that data in your warehouse.”
   • [claimed-docs] “Hightouch provides SDKs for browser, iOS, Android, Node.js, and other platforms, plus an HTTP API for server-side ingestion”
   • [claimed-docs] “Hightouch's HTTP Tracking API enables you to record data from any website or application.”
   • [claimed-docs] “Hightouch provides SDKs for [browser](/docs/events/sdks/browser), [iOS](/docs/events/sdks/ios), [Android](/docs/events/sdks/android), [Node.…”
   • [claimed-docs] “You instrument your app, site, or backend with a Hightouch SDK, the HTTP API, or a streaming source like Kafka or Google Pub/Sub.”
   • [claimed-docs] “Identity Resolution links related customer records into unified identities in your warehouse, so every downstream product works from one con…”
   • [claimed-docs] “Golden Record — a one-row-per-identity table of canonical field values (selected by survivorship rules) that many teams use as their source-…”
   • [claimed-docs] “Models — Define reusable datasets with SQL, dbt, or a visual builder”
   • [community] “Hightouch's hybrid architecture stores no data in Hightouch itself out of the box—it all stays in the customer's own warehouse/S3 bucket—whi…”

   proof ↗⚑ flag