What Piskes Analytics Strips From Custom Event Properties
Every custom event property Piskes Analytics receives is sanitized before storage — here's exactly what gets dropped and what gets truncated.
If you're sending custom events to Piskes Analytics with your own property data attached, it's worth knowing exactly what happens to those properties before they're written to storage — because not everything you send is kept as-is.
Two rules, applied to every event
Every event's properties payload passes through a sanitization step before it's stored, and that step does two things consistently: it drops any property key that matches a sensitive-key pattern, and it truncates any string value longer than 2,000 characters. This isn't an opt-in setting — it applies to every custom event, every time, with no per-workspace override.
Why this exists
Custom event properties are free-form by design — you decide what to attach to an event. That flexibility is exactly why a consistent, automatic filter matters: without one, a key named something like a password, token, or secret field could end up logged as ordinary event data by accident, or a runaway string value could bloat storage for no analytical benefit. Stripping matching keys and capping string length closes that off at the point of ingestion, rather than relying on every integration to self-police what it sends.
What this means for your integration
If a property you're sending isn't showing up on the other end, check whether its key looks like it could match a sensitive-data pattern (credentials, tokens, and similarly named fields are the ones to watch for) before assuming it's a bug. And if you're attaching longer text values — a search query, a form field, a note — expect anything past 2,000 characters to arrive truncated, not rejected. Keep properties short, structured, and free of anything sensitive, and they'll pass through untouched.