firebase-ios-sdk: BUG: Duplicate `screen_view` Events without `screen_name`

Hi all, I’m a time traveller from 2024, we are still waiting for a fix.

Looked into this and this is happening due to the following:

For iOS, we intercept screen changes to automatically log a screen view event. This is how we are able to do automatic screen view reporting. The first and second screen_view (FoodPickerViewController and ViewController without the “firebase_screen”) are logged because of this. The third screen_view event is due to the quickstart app calling setScreen manually.

This is working as intended as of now, however we may want to re-visit this in the future and possibly do some sort of de-duping screen_view events based on parameters.

We have also encountered this bug, and it took me quite a while to figure out that it was the screen name setting which was causing the issue. I’ve since been in contact with some helpful Google support members who tell me this is behaving as expected.

I am astounded that this bug - and it is a bug, no matter how you try to slice it - has existed for so long, and that its presence to Google receives absolutely no concern or priority. It is embarrassing and has drastic consequences on measurement. In the iOS header documentation, the class actually tells you how to use this API, and doing so by their instructions leads to duplicate events.

Here’s a note to the misguided engineers who claim that this is not a problem:

1. Marketers do not understand class names and we do not want to report our analytics in that way.
2. Some view controllers are used in various contexts, and therefore reporting the class name is largely useless.

FIX THIS NOW or LET US REPORT OUR OWN SCREENS ACCURATELY BY OURSELVES.

Thank you for your concerns. We agree that the current duplication of screen view events is an issue and are planning on making improvements. I will update this thread once we have something more concrete.

All, thanks for your patience. We’re currently wrapping up a beta and finalizing testing before preparing for a launch. Stay tuned on our public documentation.

The point is that it then reports DOUBLE, which is terrible.

Hi @rickydameliocroc, I apologize for the delay. We’ve had discussions about this internally and we realized that we cannot simply change the behavior of setScreen to only fire one screen_view event per ViewController as developers may already depend on the current behavior of a screen_view event per call to setScreen. An example of this is an application where one ViewController may be used for different revolving views, and setScreen is called multiple times within one ViewController with a different name.

That being said, we are still trying to balance this alongside our current projects. Unfortunately I do not have a definite time on when the fix will be delivered.

Any updates on this? This bug is a obviously dealbreaker for clients that want to track screen views in iOS apps.

314 days since Google have had a reproducible case of this bug, and not a mention of a fix or workaround… What a disgrace.

This wouldn’t be so bad if Google Analytics customers hadn’t been forced to move to Firebase for mobile analytics. We were forced to move to Firebase and the simplest analytics functionality (screen views) is broken and apparently won’t be fixed?

Am I missing something? It’s hard to believe Google or any customer would do this.

I would prefer a full manual setting at this stage, one setScreenName produces one message sent. Auto probably is all very nice if and when working, but having to manage a little extra code myself, when views display or load, for accurate tracking that can be used is worth far more for me.

@allenktv So what you’re saying is that using Firebase for iOS is rather useless? As there’s no good way for us to compare Android and iOS tracking when we can’t set the screen name.

Is there no way for us to disable the automatic screen view and only do manual reporting with a correct screen name?

@allenktv I don’t completely understand your problematic example scenario, or rather why fixing the issue would be a problem. I’ll recap it here to be sure I understood you correctly:

Premise: A ViewController that displays several views which the developer wants to be treated as separate screens. The app also uses manual screen tracking. (This is, more or less, how your quickstart example works)

What they “depend” on (rest of this post was edited after clarification by @allenktv below):

1. The first time the ViewController is shown, the current behavior, without any additional code (i.e. a manual call to setScreenName) results in a “regular” screen_view event. This does not (?) have a screen_name. The developer is happy with that, i.e. knows and expects that to be this way in firebase.
2. A user interaction flips the views in that controller and the developer added an according setScreenName to the relevant logic for that (in the ViewController). This results in a second event in firebase, this one with the a screen_name. The developer knows and expects that (and is probably not happy about this…).
3. Optionally, the app may allow “flipping back” the view controller’s looks into the initial state. This time, an according event has to be generated manually with setScreenName, but it must mimic the automatically generated one (otherwise you would get two distinct screens in your analytics). So you need to reset the name to nil.

After the edit I realize this is the flow you don’t want to break, the flow developers may depend on. There are ways to ensure that, but I see that some can be complicated. I want to point out, though that I believe above app design to be an unreasonable approach to the tracking in the first place:

1. This setup means that the developer isn’t interested in setting a screen_name for all their screens. In fact, they can’t. Stakeholders would thus have to deal with a mix of class names and screen names. Yeah…
2. I cannot use the same view controller class for several instances in my app flow and distinguish them by name. Otherwise distinct screens will be sorted into the same in the analytics, because their class is the same and they don’t have different screen names. This can be confusing when musing over how and where users navigate.

I think it’s much more common for people to simply want to use setScreenName in viewWill/DidAppear or viewDidLoad or the like to indicate “I now want to designate the current look of the app a name for analytics stakeholders to understand”. In fact, your own example app looks like this. It implies using the SDK that way in this context, imo.

For what it’s worth, in my case, I simply work with what I got. My app sets screen names where I need them and I’ve told my stakeholders to basically just ignore everything that doesn’t have a screen name. Of course those autogenerated events still count for all the timing calculation firebase does, so the percentages on which screens users stay are not correct. Luckily in my case, they’re still okay when comparing the relevant ones to another (“they spend more time here than there” is enough for us).

As two side notes:

1. If changing this would indeed mess with some sort of dependency people have on it, that’s what semantic versioning is for. Your release notes are always very good, so I think it could be argued that every developer should be well informed about anything they need to change in their code once setScreenName no longer produces double events. The only thing that cannot be fixed by us would be the, well, wrong data that’s already in firebase, but that slowly “fades away” with time I guess (i.e. I wouldn’t expect a cleanup by you guys)
2. This entire ordeal reminds me strongly of #1686. I understand your desire to use swizzling and other tricks to make the SDK integration as easy as possible, but to be honest I get the impression that approach is ill prepared for how people accomplish things on iOS. Just as you assume a developer’s intent by checking at run-time whether a framework was included in a project or not in the linked issue, here you assume that view controllers are used in a particular way. That apparently results in not giving us the option to completely manage screen name tracking ourselves with a simple, one-event-producing setScreenName. In my opinion a solution to this issue here would be to simply introduce a “SET_MANUAL_SCREEN_TRACKING_OFF” variable to the GoogleService-Info.plist and document that if set to YES, you have to use setScreenName to always manage the tracking yourself. That is just more flexible.

@allenktv there needs to be more responsiveness about this. We even pay for a subscription for this. At the very least we should get a timeline on when this will be changed.

Hi,

I just see that this is still ongoing and now we just switched away from Google Analytics because of Google’s own warnings that it would stop working and that now we can’t get the tracking working at all because it doesn’t work properly in Firebase?

@allenktv no offense but this can’t be in the “planning” phase, this is critical software and data that companies actually rely on very seriously. People depend on this.

The current situation is not good, I am also seeing (not set) and the duplicate events being tracked. You should not be swizzling viewDidAppear. You should not be swizzling anything.

There are consequences to this. For example UIAlertController also gets a viewDidAppear, and that gets tracked. How do you exactly set a screen name for that? Subclass every UIAlertController to be used in the app? What if we don’t want to track alerts or action sheets?

This bug needs to be a top priority fix. Let us track screens manually. The current approach is broken (and when SwiftUI becomes mainstream even more so).

Happy birthday, thread!

Please realize that we want to get this fixed ASAP as well, but that we also have to balance this alongside other issues and features.

This product forcefully replaced Google Analytics for mobile. Are there really other features that are more important than this basic analytics functionality?

@allenktv

We’ve had discussions about this internally and we realized that we cannot simply change the behavior of setScreen to only fire one screen_view event per ViewController as developers may already depend on the current behavior of a screen_view event per call to setScreen.

I think we are all, as a community of users of your platform, really struggling to understand your thinking on issues like this. It seems like you simply don’t care.

Regardless of what some people may or may not be used to, you have an analytics platform which is automatically doubling most data, without any possible fix. It is tantamount to having accounting software which reports twice your revenue. This is simply an error, there is no other way to reposition it.

Guys, Any updates on this?

+1 to needing a better solution here. I’d like to send a custom screen name with the views so if classes get renamed, the analytics data is not impacted (as the firebase_screen_class would change in that case). But obviously, having screen views tracked incorrectly is worse right now.

On behalf of the Google team working on resolving this, we appreciate all the input and follow ups. As my colleagues have mentioned previously, we’ve been working on a broader change to screen view tracking that would allow you to have manual control over if/when a screen_view is logged. This feature is central to our app measurement and so we’re trying to be very thoughtful and thorough with how we’re designing and implementing this solution. The good news is that we’re making progress and now testing the feature. While I can’t commit to a release date, I can say that we have a team actively working on this. Lastly, I recognize this thread has a long history and appreciate your continued patience.

I have just one word seeing this whole thread and how long this issue with a basic necessity has persisted: disappointed!

@allenktv Could you please elaborate on how this can be “working as intended” as we get double events reported?

In our situation, the automatic reporting reports the screen without the screenName, if we include setScreenName the screen view is reported TWICE. Meaning we get duplicate reports of the same screen view.

Could you be so kind to elaborate? Or let me know if there’s something we’re missing/doing wrong!

Would be greatly appreciate 👍

While I can’t commit to a release date, I can say that we have a team actively working on this. Lastly, I recognize this thread has a long history and appreciate your continued patience.

Can you commit to that release date yet? We’ve been being patiently patient with patience for a while now, so at least a ballpark estimation would be nice as a gift for my second birthday together with this bug that is fast approaching. Like, a few weeks, months, or another year… 🤦‍♀️

Happy new year! Hang in there, we had the work prioritized on both platforms (iOS and Android). We are ironing out some other changes that depends on this and we will be releasing it soon.

I add my comment also to show my deep disapointment… Google force us to change to Firebase, and I still have not seen any benefit: I lose analytics historic data, issues in IOS sdk for hundred days that IMMO are basic test any with understanding of the bussiness would do, compare analytics with firebase analytics, using the firebase examples… and results are different… ?¿?¿? I am starting to search for Firebase Analytics alternatives, sadly…

@sirshannon @bbarenblat I’m sorry to hear that. Despite this is a terrible situation, Analytics team is doing their best to accommodate feature requests. We are actively working on this (see @allenktv and @GeroHerkenrath discussion above).

There are two issues here and I will tackle them separately: (1) duplicate screen_view events; (2) high latency to reply/solve these kind of bugs/feature requests.

(1) We will be prioritizing this feature during Q4 and possibility launching this on Q1. Analytics team is investigating a clean interface for disabling features (not only screen_view and not only for iOS) that doesn’t interfere with other functionalities that we have in our roadmap. I know it sounds like we are over-engineering it, but we have to take this in consideration otherwise the dev team won’t scale. Please, bare with us while we try to fix this.

(2) Despite it is very frustrating having an issue pending for long time, the team is doing their best to accommodate these requests. Unfortunately, the team failed to properly communicate the state of some issues (e.g. #230) or it doesn’t get prioritized in timely manner.

Thank you for the feedback and hopefully my answer was as helpful as yours.

Any updates on this guys? @allenktv @paulb777

@allenktv I’m really curious : what is the technical reason for Firebase to block manual screen tracking when automatic screen tracking is disabled ?

For my current project, we’ll use events with specific names to cope with this restriction.

How exactly is this supposed to be used if we want manual-only tracking?

This feature is central to our app measurement

It was also central to many existing google analytics customers’ mobile app measurement. Then we were forced to move to Firebase where it is no longer supported correctly. For the last 2 years, we’ve been forced to do without that central app measurement feature.

and so we’re trying to be very thoughtful and thorough with how we’re designing and implementing this solution

If only the same thought was put into it before forcing your customers to move from a working mobile analytics platform to firebase in October 2019.

@GeroHerkenrath

Thank you for your thoughtful response. Just to clarify your second point: “2. user interaction flips the views in that controller and the developer added an according setScreenName to the relevant logic for that (in the ViewController). This results in two events in firebase, one without and one with the new screen_name. The developer knows and expects that (and is probably not happy about this…).” Calling setScreen in this case would only result in one screen_view event. The reason why developers are seeing two screen view events are because of the automatic screen_view (1), and calling setScreen (2). Any subsequent calls to setScreen without a new UIViewController actually just logs one screen_view event.

For example, a developer who uses one UIViewController and calls setScreen 3 times, would result in a total of 4 screen_view events.

@jaysmackie I agree. There is a proposal for a two-part change, one that fixes the current call to setScreen to not log another screen_view event, and instead append the parameters to the original screen_view event. In addition, I believe it would be best to include a manual-only screen view reporting, which would let the user manually call setScreen without having to deal with automatic tracking.

As a note: Please realize that we want to get this fixed ASAP as well, but that we also have to balance this alongside other issues and features. Thank you all for being patient.

the Analytics team has not forgotten about this feature request.

👍 on an update from @morganchen12 and also agree this should be considered a bug.

If I follow all current instructions/docs and use the provided sample code as-is I get duplicated screen views and the resulting analytics data is wrong. For an analytics product reporting accurate data should not be considered a nice-to-have or feature request…

I guess firebase is done by one guy in his spare time, is not possible this is a serious company supported by Google, come on…

M.Y.

On 4 May 2020, at 17:21, Sandeep Pathak notifications@github.com wrote:

I am surprised this issue is still open for around 20 months 😮

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

Since Google are ignoring this issue, I thought it might be worthwhile giving this thread an actual purpose and asking others out there, what analytics solutions other than Firebase have you considered? We are looking to change from Firebase Analytics, open to hear suggestions.

If the current behaviour of calls to setScreenName being a ignored when auto screen logging is disabled could be removed that would do fine. Then we could manually set the name each time we wanted something logged. Is it possible to ignore the plist flags and always perform this function?

Is this major defect going to be investigated or is it just going to be left as is? It renders screen view reporting useless for a consolidated view across two platforms.

For full transparency (especially to those subscribed for emails) - here are the release notes from today’s 6.29.0 release:

Added support for manually logging screen views with logEvent(_:parameters:). The setScreenName(_:screenClass:) API will be deprecated and removed in a future major release.

https://firebase.google.com/support/release-notes/ios#analytics

Obviously is a BUG, in upper case.

M.Y.

On 5 May 2020, at 13:44, Sandeep Pathak notifications@github.com wrote:

@morganchen12 Can we please unanimously called it a Bug and not feature request?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

@morganchen12 Can we please unanimously called it a Bug and not feature request?

Fully agree, I already reported directly too google, more people should do it…

M.Y.

On 15 Mar 2020, at 14:31, phamthoidinhthien notifications@github.com wrote:

It is ridiculous that an Analytics tools from Google can’t do a basic task: measure numbers of screen views. And what ridiculous more is that they took more than 1 years prioritizing but still can not fix it 🤷‍♂️

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

@loevborg I’m sorry on not providing any update for a while. I don’t have fully visibility of the status as I’m not directly working with the development team anymore.

As far as I know, the eng team has expanded the scope of this “fix” and they are working towards making the changes on both platforms.

Sadly, no solution

M.Y.

On 4 Dec 2019, at 12:26, udaisubramaniam notifications@github.com wrote:

Still facing this, is there a fix for this yet?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

We’ve also a problem with events reported twice, with name “(not set)” in some cases where we know the Tracking-Name only after an ajax-call:

1. We open our ArticleDetailViewController
2. We do not override the viewDidAppear method to call the setScreenName
3. We initiate the AJAX-Call to our Server what returns a JSON with the Article-Content
4. We call the setScreenName("article-title", null)
5. In Firebase we see some events reported twice, probably these where from the viewDidAppear and the AJAX-Reponse and the call to setScreenName passed too much time?

On Android we’ve another Problem with the automatic screen tracking:

• We have only one activity what loads some Fragments
• The Automatic Screen Tracking always automatically tracks the MainNavigationActivity
• In every fragment we perform the tracking like this .setScreenName("title", "FramgentClassName")
• In this case we have double reported screen_views what causes the number of total page-views to become a “unusual” number.

Additionally since the shutdown of the Analytics SDK’s we have Class-Names in the Analytics Dashboard what are irrelevant for marketers.

As I read the thread there is no really solution to solve this, and also not an expected time when google will release a fix/workaround for this issue - but how can I prevent the “(not set)” screen-Events in Firebase with the async request? @allenktv

We thought to implement one of these Workarounds:

• Send custom Events for page Tracking and create Custom Dashboards in GA as the current Firebase-Dashboards are very limited and not so helpful
• Filter out the “(not set)” events in the Dashboard
• Migrate to another Analytics/Provider

What is your workaround in this issue?

@morganchen12 That doesn’t seem true.

At leaast not according to this answer on SO here: https://stackoverflow.com/questions/44746794/disabling-firebase-automatic-screen-reporting

Google Analytics for Firebase does NOT support the case of manual-only screen reporting. The plist flag FirebaseAutomaticScreenReportingEnabled has been renamed to FirebaseScreenReportingEnabled to reduce that confusion. We support automatic + manual screen reporting or no screen reporting at all.

All, we have changes coming on the Android side. Our Android release cycle trails iOS and so our documentation won’t be updated until that’s available. It should be coming out in the next week or so.

On Thu, Jul 30, 2020 at 12:31 AM Florian Monfort notifications@github.com wrote:

If so, it isn’t obvious (to me) how to turn it off or log the events explicitly in Android.

This page https://firebase.google.com/docs/analytics/screenviews#java still documents the “automatic” method, and I don’t see any release notes or documentation anywhere about it.

Hmmm good observation, now I’m thinking I might put on hold my plans again to implement this until we get some further clarification.

Maybe @allenktv https://github.com/allenktv or @paulb777 https://github.com/paulb777 have some pointers?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-ios-sdk/issues/1894#issuecomment-666189365, or unsubscribe https://github.com/notifications/unsubscribe-auth/APROAYFXEDOQI57T76ZSHZLR6EOURANCNFSM4FYLLU4Q .

–

Kevin Lam | Product Manager | kevinklam@google.com | 949-261-4202

@mbuchetics You are able to set FirebaseAutomaticScreenReportingEnabled to NO in the Info.plist which disables all automatic screen view events, and you are still able to call logEvent(kFIREventScreenView) to manually log events at your choosing, although we still recommend that it is called in viewDidAppear, similar to setCurrentScreen. Furthermore, setting the kFIRParameterScreenName and kFIRParameterScreenClass parameter will set screen_name and screen_class respectively to future events.

An official blog post will be coming soon for further explanation. https://firebase.google.com/docs/reference/ios/firebaseanalytics/api/reference/Constants#kfireventscreenview

Any update on this ?

On behalf of the Google team working on resolving this, we appreciate all the input and follow ups. As my colleagues have mentioned previously, we’ve been working on a broader change to screen view tracking that would allow you to have manual control over if/when a screen_view is logged. This feature is central to our app measurement and so we’re trying to be very thoughtful and thorough with how we’re designing and implementing this solution. The good news is that we’re making progress and now testing the feature. While I can’t commit to a release date, I can say that we have a team actively working on this. Lastly, I recognize this thread has a long history and appreciate your continued patience.

We dont have another option rather than be patient, but google has destroyed the history of my app (5 years) and not firebase have generated garbage data since we were forced to change to it…

M.Y.

On 12 May 2020, at 02:03, kev-lam notifications@github.com wrote:

On behalf of the Google team working on resolving this, we appreciate all the input and follow ups. As my colleagues have mentioned previously, we’ve been working on a broader change to screen view tracking that would allow you to have manual control over if/when a screen_view is logged. This feature is central to our app measurement and so we’re trying to be very thoughtful and thorough with how we’re designing and implementing this solution. The good news is that we’re making progress and now testing the feature. While I can’t commit to a release date, I can say that we have a team actively working on this. Lastly, I recognize this thread has a long history and appreciate your continued patience.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

Yeah, maybe it is not a technical bug because this is how “the feature” was designed (It happens in both Android and iOS SDKs). It is just a bad design. So it is Google’s responsibility to accept it and change the behaviour asap. We all agree that this bad decision is causing many problems to a lot of people.

I am surprised this issue is still open for around 20 months 😮

+1 Having the same issue. No resolution yet?

I have lost 7 years history of my apps I had in google analytics, for this AMATEUR product that after so many months that google force use to use, is still not working …

M.Y.

On 17 Apr 2020, at 15:39, martin-suarez notifications@github.com wrote:

I cant´t believe this haven´t been fixed yet! I´d expect a lot more from this product and the company behind it …

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

As per google docs: “If you implement viewDidAppear in your UIViewController but do not call [super viewDidAppear:], that screen class will not be automatically tracked.”

When we do this we’ll have many other problems what can occur, because then some Default UIViewController internal calls would also be affected - so this is not a “real” workaround to prevent this.

Google should provide a clean solution for this issue, that can’t be so hard… 😡

Great answer, each day produce garbage data in many companies …

M.Y.

On 28 Feb 2020, at 03:54, Florian Monfort notifications@github.com wrote:

@morganchen12 we’re going to need something better than “no estimate”. We’ve gone from no answer, to there is an answer, then no news then an almost no answer.

This has been the case for a year and a half now… Do we all need to remind you this is an actual “bug”, that is causing all kinds of problems in data that entire businesses rely on to make decisions?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

@fekberg you can manually track screen names. You can also disable automatic screen reporting by setting the FirebaseScreenReportingEnabled in your Info.plist file to NO.

@danilobuerger FirebaseAutomaticScreenReportingEnabled is the correct one, although they will both work.

Why isn’t there just a quick way to disable screen_view tracking completely and let the developers manually invoke the event with their own logic 🤕

I cant´t believe this haven´t been fixed yet! I´d expect a lot more from this product and the company behind it …

It is ridiculous that an Analytics tools from Google can’t do a basic task: measure numbers of screen views. And what ridiculous more is that they took more than 1 years prioritizing but still can not fix it 🤷‍♂️