RudderStack vs mParticle

Agent access

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

   weight 2 · round to RudderStack
   RudderStack✓fullprobed8/10

   A direct probe confirms llms.txt is live at https://www.rudderstack.com/llms.txt returning HTTP 200 with a descriptive summary, directly satisfying the story of pointing an agent at agent-oriented docs; this is further complemented by dedicated MCP docs for agentic access. Missing for 10: no evidence of full llms-full.txt or markdown-per-page docs (the .md probe 404s) and no independent/community corroboration of agents actually consuming llms.txt.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.rudderstack.com/llms.txt # rudderstack.com > RudderStack's customer data infrastructure enables you …”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.rudderstack.com/docs/.md”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   RudderStack~partialprobed5/10

   RudderStack's open-source server is a standalone, self-hosted system dependent only on PostgreSQL, and it exposes HTTP APIs plus a Node SDK that can be installed and invoked programmatically (confirmed via a keyless npm install/require test), which supports headless/scripted use in CI-like pipelines. However, there is no explicit documentation of a CLI, CI-specific setup, or automation/testing guidance for pipelines. Missing for 10: explicit CI/CD integration docs or examples, a dedicated CLI tool, and evidence of automated test/deploy workflows.

   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL)”
   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL).”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Send event data from source to connected destinations”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official @rudderstack/rudder-sdk-node installed keylessly from npm into a throwaway fixture and its…”

   proof ↗⚑ flag

   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

3. ai-native userUse an official CLI

   weight 2 · round drawn
   RudderStack—none0/10

   Evidence covers RudderStack's SDKs, APIs, MCP server, and dashboards, but there is no mention of an official CLI tool for managing or interacting with RudderStack from the command line. missing for 10: any documentation or reference to an official CLI, its installation, or its command set.

   ⚑ flag

   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

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

   weight 3 · round drawn
   RudderStack✓fullprobed8/10

   RudderStack documents a full public REST API (event ingestion, Pixel API for GET-based tracking, and management endpoints for transformations/libraries) explicitly aimed at programmatic control of connections, transformations, and other features, plus SDKs (Node, JS) confirmed installable/loadable via runtime probe. This is complemented by an official MCP server (mcp.rudderstack.com) that responds correctly to protocol probes, enabling AI agents to drive the product via natural language/API. Missing for 10: a published OpenAPI/swagger spec (probe found all candidate spec URLs 404) and independent third-party corroboration of the REST API's completeness beyond vendor docs.

   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Complete Pixel API reference for tracking events via `GET` requests when `POST` is not feasible”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Manage your RudderStack Transformations and Libraries”
   • [claimed-docs] “Complete Pixel API reference for tracking events via GET requests when POST is not feasible”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official @rudderstack/rudder-sdk-node installed keylessly from npm into a throwaway fixture and its…”
   • [probe] “official MCP server documented at https://www.rudderstack.com/docs/ai-features/rudderstack-mcp/”

   proof ↗⚑ flag

   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

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

   weight 2 · round to RudderStack
   RudderStack~partialprobed4/10

   RudderStack's hosted MCP server requires OAuth Bearer authentication (401 challenge with resource metadata) rather than being open, which implies some credentialed, per-client access control for agents connecting via Claude/Cursor/etc. However, there is no documentation of scoped or least-privilege permission tiers (e.g., read-only vs. write, workspace/action-level scopes) for these credentials — the pack only shows general API/token references (rudderstack-docs-33, rudderstack-docs-47) without any granular scoping mechanism described. Missing for 10: explicit documentation of scope/permission levels for API tokens or MCP OAuth grants, ability to restrict an agent to specific actions/resources, and any independent confirmation that scoping works as intended.

   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Manage your RudderStack Transformations and Libraries”

   proof ↗⚑ flag

   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

6. ai-native userBuild against official SDKs

   weight 2 · round to RudderStack
   RudderStack✓fullprobed8/10

   RudderStack documents official SDKs (JavaScript, and Node.js confirmed via runtime probe install), a full API reference, and an official MCP server for AI-agent integration, with independent runtime confirmation of both the Node SDK package and the live MCP endpoint. missing for 10: independent third-party hands-on reviews of the SDKs themselves (beyond the npm install probe) and broader multi-language SDK evidence beyond JS/Node.

   • [claimed-docs] “RudderStack's JavaScript SDK lets you track customer event data from your website and send it to your specified destinations.”
   • [claimed-docs] “RudderStack’s JavaScript SDK lets you track customer event data from your website and send it to your specified destinations.”
   • [claimed-docs] “Load specific SDK features on demand using plugins.”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [probe] “official MCP server documented at https://www.rudderstack.com/docs/ai-features/rudderstack-mcp/”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official @rudderstack/rudder-sdk-node installed keylessly from npm into a throwaway fixture and its…”

   proof ↗⚑ flag

   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

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   RudderStack—none0/10

   No evidence pack item describes a webhook destination or webhook subscription mechanism for consuming RudderStack events; only generic references to '200+ third-party tools' and APIs are given, none naming webhooks specifically.

   ⚑ flag

   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

Agentic features

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

   weight 2 · round drawn
   RudderStack~partialprobed5/10

   RudderStack documents AI-powered features (Rudder AI Slack agent, RudderStack MCP) that let users interact with their workspace via natural language, including root-cause analysis, pipeline debugging, and one line stating AI chat interfaces let business teams 'analyze, segment, and activate data' without data-team bottlenecks. This gestures at AI-generated insights from data, but most MCP/AI documentation centers on operational tasks (debugging errors, writing transformations, detecting duplicate event names) rather than substantive data insights or suggestions about customer data itself. Missing for 10: dedicated analytics/insight-generation features (e.g., anomaly detection, trend summaries, predictive suggestions) with concrete examples or independent corroboration of AI-derived data insights.

   • [claimed-docs] “AI powered chat interfaces give everyone safe, on demand access to rich customer context and empower business teams to analyze, segment, and…”
   • [claimed-docs] “Rudder AI Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “Investigate destination delivery errors and get root cause analysis”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to mParticle
   RudderStack~partialprobed4/10

   RudderStack's core pipeline features (event streaming, reverse ETL syncs, transformations, audience syncs) run continuously/automatically once configured, which is a form of background automation, and its MCP server/Rudder AI Slack agent let AI clients interact with the workspace. However, these AI features are described as interactive/on-demand (chat-based debugging, natural-language queries) rather than autonomous agents that trigger and run automations independently in the background. Missing for 10: evidence of AI-triggered autonomous workflows, scheduled/event-driven agent actions, or agent-initiated pipeline changes without human prompting.

   • [claimed-docs] “Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “Rudder AI Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”
   • [claimed-docs] “Reverse ETL Sources Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “Transformations let you filter, enrich, and reshape event data before it reaches your destinations.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to RudderStack
   RudderStack~partialprobed7/10

   RudderStack documents 'Rudder AI', an AI-powered agent in Slack for managing/interacting with the workspace, plus AI/MCP features letting users delegate tasks in natural language (debug delivery errors, write/test transformations, review audit logs, detect duplicate events) with root-cause analysis and citations. This shows a genuine built-in AI assistant capability, though the MCP-based agentic features actually run through external clients (Claude, Cursor, etc.) rather than a fully self-contained in-product assistant, and there is no independent/hands-on confirmation of the Slack agent's real-world task delegation. missing for 10: independent/hands-on validation of Rudder AI in Slack actually completing delegated tasks, clarity on whether Slack agent operates fully in-product vs. relying on MCP/external LLM.

   • [claimed-docs] “Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “Rudder AI Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “AI powered chat interfaces give everyone safe, on demand access to rich customer context and empower business teams to analyze, segment, and…”
   • [claimed-docs] “Investigate destination delivery errors and get root cause analysis”
   • [claimed-docs] “Find event names on my JavaScript source that look like duplicates or typos.”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to RudderStack
   RudderStack✓fullprobed8/10

   RudderStack ships an official MCP server (and a Slack-based 'Rudder AI' agent) that lets users debug delivery errors, monitor pipelines, write/test transformations, and review audit logs 'all through natural language,' compatible with Claude, Cursor, Copilot, etc. A runtime probe confirms the hosted MCP endpoint is live and enforces OAuth as documented, corroborating the docs claims beyond marketing copy. Missing for 10: independent/hands-on user reports evaluating the natural-language experience itself (only vendor docs and a connectivity probe, no third-party usage account).

   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “Rudder AI Manage and interact with your workspace via an AI-powered agent in Slack”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [probe] “official MCP server documented at https://www.rudderstack.com/docs/ai-features/rudderstack-mcp/”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   RudderStack—none0/10

   RudderStack documents a static API reference page (rudderstack-docs-21, -33, -54) but nothing describes an interactive, runnable-example explorer; a direct probe for OpenAPI/Swagger specs at standard paths returned 404 across all candidates, suggesting no live interactive API console exists (rudderstack-probe-3).

   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Complete Pixel API reference for tracking events via GET requests when POST is not feasible”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   RudderStack—none0/10

   The probe explicitly checked for a machine-readable API spec at common locations (openapi.json, swagger.json, .well-known/openapi.json) and all returned 404, indicating no downloadable OpenAPI spec exists despite RudderStack having an API reference page.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”

   proof ↗⚑ flag

   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

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

   weight 1 · round to RudderStack
   RudderStack~partialclaimed5/10

   RudderStack docs describe an Event Playground for sending sample events and testing data flow without instrumentation, and MCP-based transformation testing against sample events before deployment — both let a user validate behavior without live production traffic. However, there's no documented dedicated 'sandbox environment' or staging workspace separate from production, no mention of environment cloning, and the self-hosted OSS option (a possible sandbox route) isn't framed as a testing sandbox. Missing for 10: explicit sandbox/staging workspace concept, docs on isolating test data from production destinations, and independent confirmation these testing tools fully prevent production data exposure.

   • [claimed-docs] “Use RudderStack's Event Playground app to send sample events to RudderStack and test the data flow without any instrumentation.”
   • [claimed-docs] “Use RudderStack’s Event Playground app to send sample events to RudderStack and test the data flow without any instrumentation.”
   • [claimed-docs] “Write transformation code and test it against sample events before deploying”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL)”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   RudderStack—none0/10

   The evidence pack documents RudderStack's APIs, SDKs, and MCP server but contains no mention of API versioning scheme or a documented deprecation policy; the OpenAPI probe explicitly returned 404s, showing no discoverable formal API spec artifacts either.

   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”

   proof ↗⚑ flag

   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

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 mParticle
   RudderStack—none0/10

   RudderStack's MCP server is explicitly scoped to operational/observability tasks—debugging delivery errors, monitoring pipelines, writing/testing transformations, reviewing tracking plans and audit logs (docs-13/14/15/16/48/52/53)—with no documented capability to query customer data or create/activate audiences via API or MCP. Audience building/activation (docs-6, docs-27, docs-38) is only described as a dashboard/product feature, not exposed through the documented API surface (docs-33, docs-47) or MCP tool list.

   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Audiences Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”

   proof ↗⚑ flag

   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

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 RudderStack
   RudderStack~partialprobed6/10

   RudderStack ships a documented, live hosted MCP server (confirmed via runtime OAuth probe) that lets AI clients like Claude/Cursor debug delivery errors, monitor pipelines, write/test transformations, and review tracking plans in natural language, plus a general REST API said to 'programmatically manage your RudderStack connections, transformations and other features.' However, the MCP capability list (docs-13,14,15,16,29,48,52,53) is explicit about inspecting deliveries, debugging, and transformations but never explicitly confirms agent-driven creation of sources/destinations or stream wiring, and no OpenAPI/spec was found (probe-3 all 404), leaving that part of the story thin. Missing for 10: explicit MCP/API evidence of creating sources/destinations and wiring streams, a discoverable OpenAPI spec, and independent hands-on confirmation of these write actions.

   • [claimed-docs] “Investigate destination delivery errors and get root cause analysis”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “RudderStack MCP works with any MCP-compatible client like Claude, Codex, Cursor, Visual Studio Code (GitHub Copilot), etc.”
   • [probe] “official MCP server documented at https://www.rudderstack.com/docs/ai-features/rudderstack-mcp/”
   • [probe] “PROBE runtime (recorded 2026-09-08): RudderStack's hosted remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.rudd…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”

   proof ↗⚑ flag

   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

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 mParticle
   RudderStack~partialclaimed3/10

   RudderStack markets 'AI powered chat interfaces' that let business teams 'segment and activate data' (rudderstack-docs-51), which gestures at the story, but there's no documentation of a natural-language-to-segment-definition workflow, no mention of schema grounding, or a review step before activation. The MCP feature set (docs-13/14/15/16/48/52/53) covers tracking plans, transformations, and delivery debugging via natural language, but never audience/segment building. Missing for 10: concrete docs on an AI audience-builder tool, evidence it reads the actual schema, and a review/approval UX for generated segment definitions.

   • [claimed-docs] “AI powered chat interfaces give everyone safe, on demand access to rich customer context and empower business teams to analyze, segment, and…”
   • [claimed-docs] “Build audiences and sync them to your downstream tools.”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Audiences Build audiences on warehouse sources and activate them downstream”

   proof ↗⚑ flag

   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

Activation

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

   weight 2 · round drawn
   RudderStack~partialclaimed6/10

   RudderStack documents building audiences (from warehouse or event sources) and activating them to downstream tools (rudderstack-docs-6, -27, -38), plus real-time/near-real-time event visibility (rudderstack-docs-10, -43), which supports continuous sync infrastructure. However, there is no explicit documentation of incremental/near-real-time membership updates (entry/exit) for audience sync specifically to ad platforms, nor evidence of sync frequency or refresh cadence for reverse-ETL audience activation. Missing for 10: explicit documentation of audience sync scheduling/frequency, confirmation of near-real-time membership add/remove semantics, and independent/hands-on validation of continuous audience activation to ad platforms.

   • [claimed-docs] “Build audiences and sync them to your downstream tools.”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Audiences Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “View your source and destination events in near real-time”
   • [claimed-docs] “Live Events View your source and destination events in near real-time”
   • [claimed-docs] “Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “Reverse ETL Sources Sync data from your warehouse, data lake, or database”

   proof ↗⚑ flag

   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

Audiences

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

   weight 3 · round drawn
   RudderStack~partialclaimed3/10

   Docs confirm RudderStack has an 'Audiences' feature to build audiences on warehouse sources and activate them downstream, but nothing describes a visual, no-SQL builder or size-estimation-before-activation UX — in fact the closest technical detail (Profiles/YAML generating warehouse SQL) suggests a code-driven rather than pure drag-and-drop marketer experience. Missing for 10: evidence of a visual/no-code audience builder UI, confirmation that no SQL is needed, and any mention of estimated audience size shown before activation.

   • [claimed-docs] “Build audiences and sync them to your downstream tools.”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Audiences Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”

   proof ↗⚑ flag

   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

Traits

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

   weight 2 · round drawn
   RudderStack~partialclaimed5/10

   RudderStack's Profiles feature lets marketers declare entities/attributes in YAML and automatically computes traits via feature aggregation and identity resolution (docs-19, docs-31, docs-35), and Audiences can be built on those warehouse profiles and activated to downstream tools (docs-27, docs-38). However, there is no evidence of built-in predictive modeling (LTV, churn, purchase propensity scores) — the docs only mention generic 'feature aggregation' and enrichment, not ML-based scoring outputs. Missing for 10: explicit predictive scoring models (LTV/churn/propensity) native to the product, and confirmation these scores can be directly used as targeting criteria in audience builders.

   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “You can enhance user profiles with additional data points and features.”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Audiences Build audiences on warehouse sources and activate them downstream”

   proof ↗⚑ flag

   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

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

   weight 2 · round to mParticle
   RudderStack—none0/10

   The evidence pack details single-item API/MCP actions (send event, debug a delivery error, write one transformation, review one tracking plan) but never describes a bulk/batch operation mode where an AI agent could act across many items at once. No mention of batch APIs, bulk import/export endpoints, or multi-item MCP tool calls.

   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [claimed-docs] “Investigate destination delivery errors and get root cause analysis”
   • [claimed-docs] “Write transformation code and test it against sample events before deploying”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   RudderStack~partialclaimed5/10

   RudderStack supports event-driven automation via Transformations (custom JS/Python code that runs automatically on incoming events to filter/enrich/reshape before reaching destinations), Tracking Plans that 'monitor and act on non-compliant event data', and Alerts for critical data issues — these act as rule-like triggers on events. However, there's no evidence of a general-purpose, user-defined 'if-this-then-that' rule builder with arbitrary conditions/actions beyond these fixed built-in mechanisms (transformations, audiences, consent, alerts). Missing for 10: an explicit rules/automation engine UI, documented conditional logic across arbitrary event types, and independent confirmation of custom trigger-action workflows beyond code-based transformations.

   • [claimed-docs] “Transformations let you filter, enrich, and reshape event data before it reaches your destinations.”
   • [claimed-docs] “Tracking Plans Monitor and act on non-compliant event data at the source”
   • [claimed-docs] “Alerts Get notified for critical data issues”
   • [claimed-docs] “Transformations Clean and enrich events with custom JavaScript and Python”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”

   proof ↗⚑ flag

   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

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

   weight 1 · round to RudderStack
   RudderStack~partialclaimed4/10

   RudderStack's Profiles feature uses version-controlled YAML for entity definitions, and its MCP-based AI features let users write/test transformation code before deploying and review audit logs — a partial nod to versioning/review, but there is no documented UI or feature for rolling back deployed automations/transformations to a prior version. Missing for 10: explicit rollback mechanism for transformations/pipelines, version history browsing, and independent confirmation these controls exist beyond Profiles YAML.

   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”
   • [claimed-docs] “Write transformation code and test it against sample events before deploying”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”

   proof ↗⚑ flag

   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

Destinations

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

   weight 3 · round to RudderStack
   RudderStack✓fullcommunity8/10

   Docs confirm 200+ documented destination integrations, plus per-destination transformation capability (filter, enrich, reshape events before delivery) and warehouse/event destination routing. Community testimonials corroborate real-world use for centralizing analytics routing across platforms. Missing for 10: a searchable/browsable destination catalog listing with explicit per-destination field-mapping UI documentation and independent hands-on verification of mapping/filtering granularity.

   • [claimed-docs] “Send your events to 200+ third-party tools and platforms”
   • [claimed-docs] “200+ cloud destinations”
   • [claimed-docs] “Transformations let you filter, enrich, and reshape event data before it reaches your destinations.”
   • [claimed-docs] “Send event data from source to connected destinations”
   • [community] “I recently joined Mattermost, and am currently in the midst of getting us switched over from using Segment to RudderStack. The RudderStack t…”

   proof ↗⚑ flag

   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

Ingest

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

   weight 2 · round drawn
   RudderStack~partialprobed6/10

   RudderStack documents an HTTP API for sending events server-to-source ([rudderstack-docs-21],[rudderstack-docs-33]) plus a Pixel/GET API and a Node SDK confirmed installable at runtime ([rudderstack-probe-rt-2]), implying server-to-server ingestion is supported. However, the evidence pack lacks explicit documentation of authentication mechanisms (write keys, tokens) for the HTTP ingestion endpoint, delivery-guarantee semantics (retries, at-least-once, dedup), or an OpenAPI/API reference confirming schema details — the openapi probe returned 404s. missing for 10: explicit auth/write-key documentation for the ingestion endpoint, documented delivery/retry guarantees, and a working OpenAPI spec or full API reference confirming these details.

   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Complete Pixel API reference for tracking events via GET requests when POST is not feasible”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official @rudderstack/rudder-sdk-node installed keylessly from npm into a throwaway fixture and its…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”

   proof ↗⚑ flag

   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

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 RudderStack
   RudderStack✓fullprobed8/10

   RudderStack documents a JavaScript SDK for web tracking, a Node SDK verified installable at runtime, and API/Pixel references for server-side track/identify/page-style event tracking, plus a standard event spec and Event Playground for testing. Community evidence corroborates real-world use replacing Segment for cross-platform analytics collection. missing for 10: explicit documented mobile SDK (iOS/Android) references and a single canonical spec page enumerating track/identify/page methods across all SDKs with independent hands-on confirmation for mobile/server SDKs.

   • [claimed-docs] “RudderStack's JavaScript SDK lets you track customer event data from your website and send it to your specified destinations.”
   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Complete Pixel API reference for tracking events via `GET` requests when `POST` is not feasible”
   • [claimed-docs] “Use RudderStack's Event Playground app to send sample events to RudderStack and test the data flow without any instrumentation.”
   • [claimed-docs] “Load specific SDK features on demand using plugins.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official @rudderstack/rudder-sdk-node installed keylessly from npm into a throwaway fixture and its…”
   • [community] “I recently joined Mattermost, and am currently in the midst of getting us switched over from using Segment to RudderStack. The RudderStack t…”

   proof ↗⚑ flag

   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

Sources

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

   weight 1 · round to RudderStack
   RudderStack✓fullcommunity8/10

   RudderStack documents 200+ cloud destination integrations plus Cloud/Reverse ETL sources that sync data from warehouses, data lakes, and databases (not just instrumented apps), and community reviews confirm real-world use consolidating analytics data from multiple platforms. missing for 10: an explicit list of supported third-party SaaS 'Cloud App' sources (e.g., Salesforce, Stripe) rather than just generic 'warehouse/lake/database' reverse ETL sources, and independent hands-on verification of a specific cloud-app source connector.

   • [claimed-docs] “Send your events to 200+ third-party tools and platforms”
   • [claimed-docs] “Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “Reverse ETL Sources Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “200+ cloud destinations”
   • [community] “I recently joined Mattermost, and am currently in the midst of getting us switched over from using Segment to RudderStack. The RudderStack t…”
   • [community] “Here at @Grofers we have been using rudder for a while. A great solution for people who want to create their customer data platform. Plus an…”

   proof ↗⚑ flag

   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

Profiles

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

   weight 2 · round to mParticle
   RudderStack~partialclaimed5/10

   RudderStack Profiles documents a warehouse-native 'store' — you declare entities/attributes in YAML and the system generates SQL that performs identity resolution and builds a customer 360 view, which data engineers can then query directly in the warehouse. However, there's no documented dedicated profile-query API (REST/GraphQL) for pulling traits, identifiers, or event history programmatically — the general RudderStack API docs cover event ingestion and connection management, not profile retrieval. Missing for 10: a first-party profile/traits query API or SDK method, explicit event-history retrieval endpoint, and independent confirmation of querying resolved profiles outside the warehouse.

   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”
   • [claimed-docs] “Build comprehensive customer 360 views in your warehouse”
   • [claimed-docs] “You can enhance user profiles with additional data points and features.”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Send event data from source to connected destinations”

   proof ↗⚑ flag

   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

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
   RudderStack✓fullclaimed7/10

   RudderStack's 'Profiles' feature explicitly resolves identities and builds a customer 360 in the warehouse via version-controlled YAML that 'handles identity resolution, incremental computation, and feature aggregation automatically,' giving data engineers a documented, configurable rules-based approach to stitching known/anonymous activity into unified profiles. Missing for 10: independent/hands-on validation of cross-device stitching accuracy, deeper documentation on specific identity-resolution rule configuration (e.g., merge keys, precedence rules), and community corroboration of this specific capability.

   • [claimed-docs] “Resolve identities and build a customer 360 in your warehouse.”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “Build comprehensive customer 360 views in your warehouse”
   • [claimed-docs] “You can enhance user profiles with additional data points and features.”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   RudderStack~partialprobed5/10

   RudderStack documents APIs for sending events (docs-21/22/54) and for managing connections, transformations, and libraries (docs-33/47), plus an MCP server that lets you debug pipelines, review tracking plans, and test transformations via natural language (docs-13/14/16/48). However, there's no evidence of a comprehensive OpenAPI spec or full CRUD parity for every UI feature (audiences, consent management, bot management, alerts) — the openapi probe returned 404s across candidate paths (rudderstack-probe-3), suggesting API coverage is narrower than the full UI surface. Missing for 10: documented API endpoints for audiences, consent management, alerts, and health dashboard equivalent to UI capabilities, and a public OpenAPI/swagger spec confirming full parity.

   • [claimed-docs] “Send event data from source to connected destinations”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [claimed-docs] “Manage your RudderStack Transformations and Libraries”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.rudderstack.com/openapi.json, https://www.rudderstack.com/swagger.json, https://www.rudd…”
   • [probe] “official MCP server documented at https://www.rudderstack.com/docs/ai-features/rudderstack-mcp/”

   proof ↗⚑ flag

   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

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

   weight 3 · round to RudderStack
   RudderStack~partialcommunity6/10

   RudderStack's architecture inherently supports data portability: it streams events to customer-owned warehouses (open formats via SQL) and offers a self-hostable open-source version depending only on PostgreSQL, plus APIs to manage connections/transformations. Community users cite 'total control of our data' as a reason to switch from Segment, reinforcing an open, no-lock-in stance. Missing for 10: no explicit documented bulk-export/data-portability feature or migration-out tooling, and no first-party statement guaranteeing full data extraction in open formats when leaving the platform.

   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL)”
   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL).”
   • [claimed-docs] “Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “Explore the RudderStack APIs to programmatically manage your RudderStack connections, transformations and other RudderStack features.”
   • [community] “I recently joined Mattermost, and am currently in the midst of getting us switched over from using Segment to RudderStack. The RudderStack t…”

   proof ↗⚑ flag

   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

Observability

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

   weight 2 · round to RudderStack
   RudderStack✓fullclaimed7/10

   RudderStack docs explicitly cite Live Events (near real-time source/destination event viewing), a Health Dashboard for pipeline metrics, Alerts for critical data issues, and MCP-powered destination delivery error investigation with root-cause analysis. These directly map to debugger views, delivery metrics, and alerting. Missing for 10: no independent/hands-on validation of the debugger UI itself or alerting reliability, and no detail on granularity of per-destination delivery metrics beyond marketing bullet points.

   • [claimed-docs] “Monitor your data pipelines and get key metrics at a glance”
   • [claimed-docs] “View your source and destination events in near real-time”
   • [claimed-docs] “Get notified for critical data issues”
   • [claimed-docs] “Investigate destination delivery errors and get root cause analysis”
   • [claimed-docs] “Alerts Get notified for critical data issues”
   • [claimed-docs] “Live Events View your source and destination events in near real-time”
   • [claimed-docs] “Health Dashboard Monitor your data pipelines and get key metrics at a glance”
   • [claimed-docs] “Debug delivery errors, monitor pipelines, write and test transformations, review audit logs — all through natural language.”

   proof ↗⚑ flag

   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

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
   RudderStack~partialclaimed5/10

   RudderStack's docs explicitly list a 'Consent Management' feature ('Capture consent and stay compliant with GDPR and CCPA'), indicating opt-in/opt-out consent capture is a documented product capability, and 'Tracking Plans' can monitor/act on non-compliant event data at the source. However, there is no detail on how consent categories map to specific destinations, no evidence of automatic per-destination suppression logic, and no independent or hands-on confirmation that opt-outs are actually honored downstream across the 200+ destinations. Missing for 10: technical documentation of consent-category-to-destination enforcement, hands-on/independent verification that opt-outs propagate correctly, and detail on supported consent frameworks (e.g., IAB TCF, OneTrust integration specifics).

   • [claimed-docs] “Capture consent and stay compliant with GDPR and CCPA”
   • [claimed-docs] “Consent Management Capture consent and stay compliant with GDPR and CCPA”
   • [claimed-docs] “Monitor and act on non-compliant event data at the source”
   • [claimed-docs] “Tracking Plans Monitor and act on non-compliant event data at the source”

   proof ↗⚑ flag

   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

Deletion

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

   weight 2 · round to mParticle
   RudderStack—none0/10

   Evidence shows RudderStack's Consent Management feature captures consent for GDPR/CCPA and Tracking Plans can flag non-compliant events, but there is no mention of a user deletion/suppression request API or workflow that forwards those requests to connected destinations. This is a fair capability to expect from a CDP (peers like Segment offer a User Deletion API), so absence of evidence is 'none' rather than 'na'.

   • [claimed-docs] “Capture consent and stay compliant with GDPR and CCPA”
   • [claimed-docs] “Consent Management Capture consent and stay compliant with GDPR and CCPA”
   • [claimed-docs] “Monitor and act on non-compliant event data at the source”
   • [claimed-docs] “Tracking Plans Monitor and act on non-compliant event data at the source”

   proof ↗⚑ flag

   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

Pii controls

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

   weight 2 · round to mParticle
   RudderStack~partialclaimed4/10

   RudderStack's Transformations feature (custom JS/Python) is documented to 'filter, enrich, and reshape event data before it reaches your destinations,' which could technically implement masking/hashing/field-level filtering per destination, and Tracking Plans/Consent Management address broader compliance. However, there is no explicit documentation of built-in PII hashing, masking, or field-level filtering controls — this would require custom transformation code rather than a native privacy-control feature. Missing for 10: dedicated PII hashing/masking UI or config, explicit field-level filtering per destination, documentation or example specifically addressing sensitive-attribute redaction, and independent confirmation of this use case.

   • [claimed-docs] “Transformations let you filter, enrich, and reshape event data before it reaches your destinations.”
   • [claimed-docs] “Transformations Clean and enrich events with custom JavaScript and Python”
   • [claimed-docs] “Tracking Plans Monitor and act on non-compliant event data at the source”
   • [claimed-docs] “Consent Management Capture consent and stay compliant with GDPR and CCPA”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   RudderStack—none0/10

   No evidence in the pack addresses data residency, regional hosting options, or geographic storage location controls for RudderStack Cloud; the pack covers open-source self-hosting (which implicitly allows control of location) but never states region selection or residency guarantees. Missing for 10: explicit region/residency selection features, documentation of hosting regions (EU/US), or compliance statements tying storage location to user choice.

   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL)”
   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL).”

   proof ↗⚑ flag

   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

2. ai-native userControl data retention and deletion

   weight 2 · round to mParticle
   RudderStack~partialclaimed3/10

   RudderStack documents consent management and general GDPR/CCPA compliance capture, but there is no concrete documentation of data retention settings, deletion APIs, or right-to-be-forgotten workflows for AI-native users to control. Missing for 10: explicit data retention period controls, a documented deletion/erasure API or workflow, and any evidence of AI-agent access to trigger deletion.

   • [claimed-docs] “Capture consent and stay compliant with GDPR and CCPA”
   • [claimed-docs] “Consent Management Capture consent and stay compliant with GDPR and CCPA”

   proof ↗⚑ flag

   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

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
   RudderStack—none0/10

   While RudderStack documents forwarding live events to destinations, syncing from warehouses, and reverse ETL, no evidence describes a mechanism to replay previously archived/ingested events into a newly added destination or backfill historical data after a pipeline outage. Reverse ETL (docs-4/docs-36) syncs current warehouse state, not archived event replay, so it doesn't satisfy the specific replay-portability need.

   • [claimed-docs] “Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “Reverse ETL Sources Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL)”

   proof ↗⚑ flag

   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

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 RudderStack
   RudderStack~partialclaimed6/10

   RudderStack's docs explicitly describe a 'Tracking Plans' feature that 'monitors and acts on non-compliant event data at the source' and lets you 'review Tracking Plans and their event schemas,' indicating schema enforcement is a first-party capability. However, the evidence never spells out the concrete enforcement mechanics (flag vs. block vs. quarantine) or shows a hands-on example of a violating event being stopped. Missing for 10: explicit documentation of block/quarantine behavior, a hands-on/community example of enforcement in action, and detail on how violations are surfaced to prevent downstream corruption.

   • [claimed-docs] “Monitor and act on non-compliant event data at the source”
   • [claimed-docs] “Tracking Plans Monitor and act on non-compliant event data at the source”
   • [claimed-docs] “Review Tracking Plans and their event schemas”
   • [claimed-docs] “Find event names on my JavaScript source that look like duplicates or typos.”

   proof ↗⚑ flag

   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

Transformations

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

   weight 2 · round to RudderStack
   RudderStack✓fullclaimed8/10

   RudderStack's Transformations feature explicitly lets users filter, enrich, and reshape event data with custom JavaScript/Python code before it reaches destinations, and MCP tooling supports writing and testing transformation code against sample events. Missing for 10: independent hands-on verification of transformation code execution/testing beyond docs, and more detail on supported languages/runtime limits.

   • [claimed-docs] “Transformations let you filter, enrich, and reshape event data before it reaches your destinations.”
   • [claimed-docs] “Clean and enrich events with custom JavaScript and Python”
   • [claimed-docs] “Transformations Clean and enrich events with custom JavaScript and Python”
   • [claimed-docs] “Write transformation code and test it against sample events before deploying”
   • [claimed-docs] “Manage your RudderStack Transformations and Libraries”

   proof ↗⚑ flag

   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

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 RudderStack
   RudderStack✓fullclaimed7/10

   RudderStack's Profiles feature lets engineers declare entities/attributes in version-controlled YAML directly against warehouse tables, generating warehouse-native SQL for identity resolution and feature aggregation, and its Audiences feature builds audiences on warehouse sources and activates them downstream without re-collecting event data, backed by dedicated Reverse ETL sources that sync from the warehouse/lake/DB. missing for 10: independent/hands-on corroboration of the warehouse-native reverse ETL workflow, and a concrete case study confirming no re-collection occurs in practice.

   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”
   • [claimed-docs] “Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Audiences Build audiences on warehouse sources and activate them downstream”
   • [claimed-docs] “Reverse ETL Sources Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “Build comprehensive customer 360 views in your warehouse”

   proof ↗⚑ flag

   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

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 RudderStack
   RudderStack✓fullcommunity8/10

   RudderStack explicitly supports warehouse/lake destinations (Snowflake, BigQuery, ClickHouse, S3-type object storage) with automatic schema management, scheduled Reverse ETL syncs from warehouses, and Profiles building customer 360 via warehouse-native SQL, giving data engineers control over landing raw events/profiles in their own infra. Community feedback corroborates 'total control of our data' and one-place data routing, and the open-source self-hosted option reinforces warehouse-native control. missing for 10: explicit named connector list/setup docs for Snowflake/BigQuery/ClickHouse/S3 destinations, and details on schedule/frequency configuration for warehouse syncs.

   • [claimed-docs] “Sync data from your warehouse, data lake, or database”
   • [claimed-docs] “you don't need to define a schema for your event data - RudderStack automatically does that for you”
   • [claimed-docs] “you don’t need to define a schema for your event data - RudderStack automatically does that for you by following a predefined warehouse sche…”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL”
   • [claimed-docs] “you declare entities and their attributes in version-controlled YAML, and the system generates warehouse-native SQL that handles identity re…”
   • [claimed-docs] “Build comprehensive customer 360 views in your warehouse”
   • [claimed-docs] “The open source version of RudderStack is a standalone system dependent only on a database (PostgreSQL)”
   • [community] “I recently joined Mattermost, and am currently in the midst of getting us switched over from using Segment to RudderStack. The RudderStack t…”

   proof ↗⚑ flag

   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