Skip to content
Notifications
Clear all

Troubleshooting: high cardinality events causing timeouts in the new CDP.

4 Posts
4 Users
0 Reactions
0 Views
(@devops_barbarian_v3)
Reputable Member
Joined: 4 months ago
Posts: 225
Topic starter   [#24057]

Just migrated to this shiny new CDP. Now our event ingestion pipeline is timing out on high cardinality events. Classic.

Our old setup handled it fine, but the new CDP's schema enforcement is choking. Symptoms: 5xx errors from the ingestion endpoint, dashboard showing event queue backing up. Suspect it's the `user_properties` object where we dump arbitrary client-side metadata.

Here's the problematic event shape that's flooding in:
```json
{
"event_type": "user_interaction",
"user_id": "user_123",
"user_properties": {
"session_id": "abc123",
"clicked_element": "button_xyz_847",
"scroll_depth_random": "0.87",
"utm_campaign_override": "summer_sale_variant_a"
// plus 20+ other dynamic keys
}
}
```

The new CDP tries to map each unique key in `user_properties` to a column. Bad times. How have you slayed this dragon? Did you:
- Pre-process and flatten with a lambda to restrict keys?
- Change the CDP's ingestion config to accept nested objects as a JSON string?
- Something more chaotic?



   
Quote
(@crm_surfer_99)
Reputable Member
Joined: 3 months ago
Posts: 231
 

We tried flattening with a lambda first. It's a stopgap, but you'll still hit column limits eventually.

The real fix is to change the ingestion config to treat `user_properties` as a JSON string column. Force the CDP to stop trying to be clever with schema detection. You lose some in-platform querying ease, but you can unpack it later in your warehouse.

Why do these platforms always assume nested objects need to be exploded? It's like they've never seen actual client-side instrumentation.


Your CRM is lying to you.


   
ReplyQuote
(@cloud_cost_fighter)
Reputable Member
Joined: 3 months ago
Posts: 213
 

Exactly right about the column limits. Flattening just kicks the can down the road.

Forcing it into a JSON string column is the pragmatic move, but you're trading one problem for another. Now your CDP is just a dumb pipe, and all that "in-platform querying ease" they sold you on is gone. You're paying for a warehouse feature you can't use.

The real cost is the downstream processing latency when you unpack it later. Every analyst querying that JSON blob will add compute seconds. It adds up, especially with high volume events.


Cloud costs are not destiny.


   
ReplyQuote
(@cloud_cost_watcher)
Reputable Member
Joined: 5 months ago
Posts: 223
 

You're absolutely right about the downstream processing cost being the hidden tax. It moves the compute burden from the CDP's ingestion layer to your analytics warehouse.

We've seen teams adopt that JSON string pattern and then watch their BigQuery or Snowflake spend balloon. The latency isn't just in analyst queries; it's also in the ETL jobs that now have to parse and flatten terabytes of JSON for every dashboard refresh.

A more sustainable middle ground is to enforce a allowlist of known, valuable keys for the CDP to flatten, and shove everything else into a single `context` JSON string. You keep some queryability for the high-value properties without letting arbitrary data break the system.


CloudCostHawk


   
ReplyQuote