Why We Killed Custom Event Properties
(And Why You Should Thank Us)

Every major analytics platform—Mixpanel, Amplitude, Firebase, PostHog—has a feature they're proud of: custom event properties. Track any event. Attach any data. Infinite flexibility.

We removed that feature entirely. Our SDK doesn't have a properties parameter. Our API rejects any data beyond 5 predefined fields. And we think this makes us better, not worse.

This isn't a limitation—it's a safety feature. Here's why.

🪤 The "Infinite Attributes" Trap

Custom properties feel like a superpower when you're building. Need to segment users? Add a property. Want to track purchase amounts? Add a property. Debugging an edge case? Log the user's input as a property.

The problem isn't today. The problem is 18 months from now when:

Every custom property is a door you're leaving unlocked. Most of the time, nothing walks through. But when it does, you have a data spill—and potentially a regulatory incident.

💀 A Real Horror Story

Here's a scenario that's happened at companies you've heard of:

The flexibility of custom properties enabled this. The developer wasn't malicious—they were debugging. But the architecture allowed a debug statement to become a 14-month data collection program.

🏗️ The Architecture of Constraint

Our approach is different. We enforce data minimization at the API level—not as a policy, but as an architectural constraint.

The Strict 5-Field Model

Every event we store has exactly 5 fields. No more, no less:

That's it. The API rejects any additional data. The SDK doesn't have a properties parameter. You can't accidentally leak PII because there's nowhere to put it.

What This Looks Like in Code

// Nothing stops you from doing this:
Analytics.track("signup", properties: [
    "email": user.email,           // ✅ Sent (and now stored forever)
    "name": user.fullName,          // ✅ Sent (PII in your analytics)
    "debug": user.toString()        // ✅ Sent (who knows what's in there)
])

// No properties parameter exists:
Respectlytics.track("signup_completed")  // ✅ That's it. Nothing else to add.

// This doesn't compile:
Respectlytics.track("signup", properties: [...])  // ❌ Error: extra argument 'properties'

// Even if you hit the API directly with extra fields:
// POST /api/v1/track
// {"event_name": "signup", "email": "[email protected]"}
// → API accepts request but silently discards "email"

🛡️ Defensible by Default

We call our philosophy Return of Avoidance (ROA)—the best way to handle sensitive data is to never collect it. But the real payoff isn't philosophical. It's practical.

The Audit Question You Never Want to Hear

Imagine an auditor—internal, external, or regulatory—asks:

"Can you confirm that no personal data has been collected in your analytics events over the past 3 years?"

With traditional analytics, answering this requires:

With architectural constraints, the answer is simpler:

This is what defensible by design means. Not a policy that developers might follow. An architecture that makes violations impossible.

📊 How to Measure Intent Without Identity

The first objection we hear: "But how do I segment users without custom properties?"

The answer: use descriptive event names instead of generic events with properties.

Event Naming Taxonomy (The Pattern)

Notice the last row. You lose the search query—intentionally. Because userQuery might be "pharmacy near 123 Main Street" or "Dr. Smith appointment." That's the kind of data that becomes a liability.

You still know searches are happening. You know how many. You know which platform. You know the trend over time. You just don't know what people searched for—and you probably didn't need to.

⚔️ The Counter-Arguments (And Our Responses)

❓ Frequently Asked Questions