AWS Clean Rooms Account Overlap¶

Capability Slug: aws_cleanrooms_analysis Plan Tier: Command Credit Cost: 15 / 20 / 25 credits per run (varies by analysis type) Category: Co-Sell Default analysis type: account_overlap Backend status: Simulation today — production AWS Clean Rooms SDK integration in progress

Backend status — simulation, not production analytics

The capability ships with a deterministic simulation backend (simulateCleanRoomsQuery()) so the full workflow — dual consent, hashed account submission, AI narrative, audit logging — is wired and exerciseable end-to-end. The actual AWS Clean Rooms SDK call is a planned production swap at the executeCleanRoomsQuery() method boundary. Until that lands, treat the numerical outputs (overlap counts, ICP match percentages, estimated pipeline value) as preview values, not production analytics. The data-sharing consent gate, audit trail, and AI insight generation are real and behave the same as they will in production.

Overview¶

Two partners running parallel AWS GTM motions almost always have customer overlap they can't see — neither side wants to share their customer list, but both would benefit from knowing where they overlap so they can run joint plays into shared accounts.

AWS Clean Rooms Account Overlap turns that into structured analysis. Both partners contribute hashed customer lists and a consent flag; the capability runs the secure overlap query through Clean Rooms (or its simulation today) and returns aggregated outputs — overlap counts, ICP match rates, opportunity prioritization, segment splits — without exposing the underlying customer identifiers to either side.

The capability is built around four analysis modes that answer different questions, an explicit dual-consent gate, hashed-input handling, and an immutable audit trail attached to the co-sell relationship.

The four analysis modes¶

Analysis type	Credits	Answers	Output highlights
`account_overlap` (default)	15	"How many customers do we share?"	`total_overlap_count`, partner totals, overlap percentage, segment breakdown, AI-generated overlap analysis
`icp_validation`	20	"Of the overlap, how many match our ICPs?"	`icp_match_count`, `icp_match_percentage`, firmographic breakdown by company size / industry / region, deterministic recommendation
`opportunity_identification`	25	"Which overlapping accounts should we co-sell into first?"	Ranked `opportunities` with priority + estimated value, top-10 prioritized list, recommended actions, `estimated_pipeline_value`
`segment_analysis`	20	"Where in the funnel does overlap concentrate?"	Per-segment overlap counts and percentages (enterprise / mid-market / SMB), `highest_overlap_segment`, segment recommendations

Models used: Claude 3 Haiku for the AI narrative on account_overlap (small, fast, cheap). ICP recommendations and opportunity prioritization are deterministic helpers, not AI.

The capability hard-fails any run where either partner hasn't opted in. Specifically, it reads partner_a_data_consent and partner_b_data_consent from the CoSellRelationship metadata, and throws if either is missing or false:

Both partners must opt-in to data sharing before running Clean Rooms analysis.
Please ensure both partners have consented to secure account overlap analysis.

This is a structural guarantee — neither side can pull overlap data on the other without explicit two-sided consent. Both consent flags are managed through the co-sell relationship UI (or via Partner API on the relationship record).

Privacy model¶

How the capability protects raw customer data:

Layer	Mechanism
Input hashing	Customer account lists are hashed (SHA-256 in production) before submission. Raw identifiers never leave the partner's environment.
Aggregated output only	The Clean Rooms execution returns counts, percentages, and segment splits — never the underlying overlapping account list.
Privacy note in every result	`account_overlap` results include `privacy_note: "No raw customer identifiers were exposed. All data was analyzed securely via AWS Clean Rooms."`
Dual consent gate	Required before any query; checked server-side.
Audit trail	Every query and result summary is logged to the relationship's metadata.

Audit fields on the CoSellRelationship metadata:

metadata.cleanrooms_queries[] — full parameter capture per query (timestamp, query type, parameters)
metadata.cleanrooms_audit_log[] — result summaries (timestamp, analysis type, success flag, record count); capped at the most recent 100 entries

Partners can review who ran what when from the relationship record without seeing the underlying data.

Required and optional parameters¶

Parameter	Required	Description
`cosell_relationship_id`	Yes	An active `CoSellRelationship` between the two partners with dual consent set
`analysis_type`	Yes	One of `account_overlap`, `icp_validation`, `opportunity_identification`, `segment_analysis`
`account_list`	Required for overlap modes	Hashed account list for the calling partner (the other side's list is read from their consent record)
`criteria`	Opportunity mode only	Custom criteria object for opportunity matching
`segments`	Segment mode only	Array of segment labels to analyze. Defaults to `["enterprise", "mid-market", "smb"]`

What `account_overlap` returns¶

{
  "success": true,
  "analysis_type": "account_overlap",
  "credits_used": 15,
  "total_overlap_count": 0,
  "partner_a_total": 0,
  "partner_b_total": 0,
  "overlap_percentage": 0,
  "segment_breakdown": {
    "enterprise": 0,
    "mid-market": 0,
    "smb": 0
  },
  "ai_insights": {
    "summary": "...",
    "insights": ["...", "..."],
    "actions": ["...", "..."]
  },
  "privacy_note": "No raw customer identifiers were exposed. All data was analyzed securely via AWS Clean Rooms."
}

The AI insights block (summary, insights, actions) is generated by Claude 3 Haiku from the aggregated overlap numbers — it's narrative, not recomputation of the underlying data.

What `icp_validation` returns¶

{
  "total_overlap_accounts": 0,
  "icp_match_count": 0,
  "icp_match_percentage": 0,
  "firmographic_breakdown": {
    "company_size_distribution": { "1-50": 0, "51-200": 0, "201-1000": 0, "1000+": 0 },
    "industry_distribution":     { "FinTech": 0, "Healthcare": 0, "SaaS": 0, "E-commerce": 0 },
    "region_distribution":       { "North America": 0, "Europe": 0, "Asia Pacific": 0 }
  },
  "recommendation": "..."
}

The recommendation is deterministic, banded by ICP match percentage:

ICP match %	Recommendation
≥ 80%	"Excellent ICP alignment! Focus joint GTM efforts on these highly qualified overlapping accounts."
≥ 60%	"Good ICP match. Prioritize accounts that fit both partners' ideal customer profiles."
≥ 40%	"Moderate ICP alignment. Consider refining target criteria to focus on best-fit accounts."
< 40%	"Low ICP match. Review and align ICP definitions before scaling co-sell efforts."

Both partners' Partner.icp_definition records feed the validator — populate them in your partner profile before running this mode.

What `opportunity_identification` returns¶

{
  "opportunities": [
    { "opportunity_id": "OPP-0001", "segment": "enterprise",
      "estimated_value": 250000, "stage": "qualified", "priority": "high" }
  ],
  "total_opportunity_count": 0,
  "prioritized_opportunities": [ /* top 10 */ ],
  "recommended_actions": [
    "Schedule joint outreach to top 5 high-priority accounts",
    "Create customized co-sell pitch for enterprise segment",
    "Set up weekly sync to track opportunity progression"
  ],
  "estimated_pipeline_value": 0
}

prioritized_opportunities is a deterministic top-10 sort: by priority bucket (high → medium → low), then by estimated value descending. The recommended actions are static templates today — they don't change based on the opportunity mix.

What `segment_analysis` returns¶

{
  "segments": {
    "enterprise":  { "overlap_count": 0, "overlap_percentage": 0 },
    "mid-market":  { "overlap_count": 0, "overlap_percentage": 0 },
    "smb":         { "overlap_count": 0, "overlap_percentage": 0 }
  },
  "highest_overlap_segment": "mid-market",
  "segment_recommendations": [
    "Focus co-sell efforts on mid-market segment (highest overlap)",
    "Enterprise segment shows good potential for expansion"
  ]
}

Pass a custom segments array if your partner motion uses different labels (e.g. ["fortune_500", "growth", "startup"]).

When to use it¶

Scenario	Recommended mode
New co-sell partnership exploration — sizing the opportunity	`account_overlap`
Pre-campaign targeting decisions	`icp_validation`
Building a joint pipeline target list	`opportunity_identification`
Deciding which segment to lead the joint motion in	`segment_analysis`
Quarterly partnership review — "are we still aligned?"	All four, run sequentially

It is not:

A CRM export. The capability needs hashed account lists from both partners as input; it doesn't pull from your CRM automatically (CRM integration for the input pipeline is on the roadmap).
A substitute for AWS Clean Rooms collaboration setup. In production mode (post-SDK swap), this capability calls into a Clean Rooms collaboration that both partners need to be members of — collaboration setup happens in the AWS console.
A real-time service. Each run executes a discrete query; results are not continuously updated.
Live data today. See the simulation-status callout at the top of this page.

Prerequisites checklist¶

Before running any mode:

Active CoSellRelationship between the two partners — set up via Partner Discovery.
Dual consent — both partner_a_data_consent and partner_b_data_consent set to true in relationship metadata.
Hashed account list ready to submit (CRM export, deduped, SHA-256 hashed in production).
For icp_validation — both partners' Partner.icp_definition populated.
For opportunity_identification — optional criteria object defining what counts as a qualified opportunity.

API access¶

The capability is exposed through the agent runtime as aws_cleanrooms_analysis. Partner API keys scoped with manage_cosell_plans plus the agent capability slug can run analyses programmatically through the agent execution endpoint. The dual-consent gate is enforced at the capability layer regardless of how the call originates. See Partner API Capabilities and Authentication & API Keys.

AWS Clean Rooms Account Overlap¶

Overview¶

The four analysis modes¶

Dual consent — required before any run¶

Privacy model¶

Required and optional parameters¶

What account_overlap returns¶

What icp_validation returns¶

What opportunity_identification returns¶

What segment_analysis returns¶