People speak of a parser as if it were a doorman: the event name is on the list, or it is not. The expensive failures happen after the name is accepted. A property arrives with the wrong type. A required identifier is an empty string. A value that should be one of three enums arrives as free text from a debug build that was never excluded.
Harith Osman’s usual pass on a mobile payload is dull on purpose. For each high-traffic event he asks: is the property present on every source? Is the type stable? Do allowed values still match the current catalogue? Does the property exist only on Huawei or HarmonyOS builds? That last question has paid for the audit more than once in Shah Alam samples.
Why “the event fired” is not a finding
If purchase fires and quantity is the string "2" on one OEM, some parsers drop the property and keep the event. The purchase count looks fine. Revenue math does not. The findings document has to say which layer dropped the field, or the engineer will “fix” the event name and leave the type mismatch in place.
We ask for parser rules in writing when they exist. When they do not, we infer drop behaviour from properties that vanish between raw export and the table the report uses. Inference takes longer and is called out as inference. It is still more honest than marking the event as valid because the name matched a list.
What we leave alone
Ads postbacks, warehouse models, and identity graphs are neighbouring problems. A validation pass that tries to swallow them becomes a tour. We stay with the payload, the parser, and the report that trusts the result. The flagship audit is written that way on purpose.