We were asked to look at an Android product whose new-user counts in the analytics property sat well below Play Console installs. Marketing assumed fraud and store reporting lag. The measurement plan said first_open should fire when the app process starts, before any screen the person could refuse.
In the build we installed, a consent dialog appeared on the first activity. The analytics SDK was initialised only after the person tapped Allow. Anyone who dismissed the dialog, or who left the app open on that screen and never came back, produced an install in Play Console and nothing in the property.
What the law requires is not the same as what the plan assumed
In Malaysia, teams often treat the Personal Data Protection Act as a reason to postpone every event until a box is ticked. That is a legal question for their counsel. From an instrumentation point of view, the plan and the build have to describe the same moment. If first_open is defined as process start, and the SDK is born after consent, the name is a lie.
There are honest versions of this. Some teams fire a tiny, non-identified launch marker before consent and attach an identity after. Some teams accept that cohorts begin at consent and rename the event. The product we reviewed had done neither. It kept the old name and the new gate.
How we check it in a session
We install on a device that has never seen the app. We do not tap the consent button. We wait, background the app, and read the log. Then we tap Allow and read the log again. If the first event in the property appears only after Allow, we write that down as a timing finding, not as a moral one.
Product teams can then take the finding to counsel and to engineering. Our job in the audit is to stop the weekly reading from assuming a day-zero that the device never sent.