The growth lead in Johor Bahru had a funnel that looked healthier after they added a second analytics SDK 'for marketing.' Step-to-step drop-offs shrank. Revenue did not move. They asked us whether the new onboarding copy was working.
It was not a copy question. Automatic screen reporting was still on in Firebase. The second SDK had been told to send its own screen_view from a base activity. Each open of the same screen wrote two events into the property they used for funnels, because a warehouse job was unioning both streams without de-duplication.
How a double fire hides in a funnel
If every step doubles, the ratios between steps can look almost unchanged, which is why the team thought the funnel had 'improved a little.' Counts of unique users, when they remembered to use them, told a quieter story. Counts of events told a louder one. The weekly email used event counts.
We sat with a proxy, opened one screen, and watched two nearly identical payloads leave, a few dozen milliseconds apart, with different SDK names in the user-agent of the request. That is a faster proof than arguing about dashboards.
The boring fix
Pick one place that is allowed to announce a screen. Turn automatic reporting off in the other SDK, or stop unioning raw screen_view into the funnel table. Write the choice into the measurement plan so the next contractor does not 'help' by turning automatic reporting back on.
Second SDKs are not the villain. Unowned screen announcements are. If both libraries are going to stay in the app, the audit has to say which one is allowed to speak for a screen, in writing, with the activity name attached.