firebase分析_为什么我在下一个项目中不使用Firebase分析

firebase分析

If I were looking for an analytics service, I would not use Firebase Analytics. It has too much cognitive overhead, too many surprises, too many things you have to do manually that it should have done by itself. (I would use Firebase’s BaaS tools, and perhaps use Firebase Analytics in that context, but not by itself, if I were just looking for an analytics service.)

如果我正在寻找分析服务，则不会使用Firebase Analytics。 它具有太多的认知开销，太多的惊喜，您必须手动完成的许多手动操作。 (如果我只是在寻找分析服务，我会使用Firebase的BaaS工具，也许会在这种情况下使用Firebase Analytics，但不能单独使用。)

⦿ Firebase Analytics does not distinguish between production and development versions of your product. As you develop your app, you’ll run it locally, and as you do this, analytics data from your local runs will get mixed with production data, corrupting it. To fix these, you need to detect such builds and call setAnalyticsCollectionEnabled(false). There are multiple kinds of builds to detect: running from Xcode or Android studio, running on the simulator, debug mode builds, and testing production builds before launch using TestFlight or other similar tool. You need to detect all these cases and disable Firebase Analytics.

base Firebase Analytics不会区分产品的生产版本和开发版本。 在开发应用程序时，您将在本地运行它，并且这样做时，本地运行中的分析数据将与生产数据混合在一起，从而损坏它。 要修复这些问题，您需要检测到此类构建并调用setAnalyticsCollectionEnabled(false)。 有多种类型的构建需要检测：从Xcode或Android Studio运行，在模拟器上运行，调试模式构建以及在使用TestFlight或其他类似工具启动之前测试生产构建。 您需要检测所有这些情况并禁用Firebase Analytics。

And you should disable Firebase Analytics before it automatically logs any events! [1] I’d call this before initialising it with FirebaseApp.configure(). According to the Firebase documentation, you should not call any Firebase functions before configure(), but I have to go against what the documentation says to get Firebase to do something it should have done by itself.

而且您应该在Firebase Analytics自动记录任何事件之前将其禁用！ [1]在使用FirebaseApp.configure()对其进行初始化之前，我会先称呼它。 根据Firebase文档，您不应该在configure()之前调用任何Firebase函数，但是我不得不违背文档中所说的，以使Firebase自行完成应做的事情。

⦿ But disabling analytics doesn’t let you test it. For example, if you add a new event, you need to run the app, open the Firebase console, and verify that it is indeed being logged. But when you do this, your production data is again corrupted by development data. To fix this, you need to create a second “dev” Firebase project, and remember to keep reconfiguring your app to switch between the dev project for development and the production project each time you run or release your app.

⦿但是禁用分析并不能让您对其进行测试。 例如，如果添加一个新事件，则需要运行该应用程序，打开Firebase控制台，并验证它是否确实已被记录。 但是当您这样做时，您的生产数据又被开发数据破坏了。 要解决此问题，您需要创建第二个“ dev” Firebase项目，并记住保持重新配置您的应用程序，以便在每次运行或发布应用程序时在开发项目和生产项目之间切换。

⦿ If you have a second Firebase project, when you open the Firebase console in your browser, it shows data from both the dev and production versions together. You should change it to production. But it doesn’t remember your choice when you open it again next week. I got wrong conclusions from Firebase Analytics because of this.

⦿如果您有第二个Firebase项目，则在浏览器中打开Firebase控制台时，它将同时显示来自开发版本和生产版本的数据。 您应该将其更改为生产。 但是下周再次打开它时，它不会记住您的选择。 因此，我从Firebase Analytics中得出了错误的结论。

⦿ This problem of the UI not remembering your choices extends further: it doesn’t remember your choices even as you navigate from screen to screen. For example, if you sort events in decreasing order, then click an event to see more details, and press back, events are no longer in order, so you’ve lost your place and perhaps train of thought.

⦿UI不能记住您的选择的问题进一步扩大了：即使您在屏幕之间导航时，它也不记得您的选择。 例如，如果按降序对事件进行排序，然后单击一个事件以查看更多详细信息，然后按回去，则事件将不再按顺序排列，因此您失去了位置，甚至失去了思路。

⦿ Some screens in the Firebase console don’t let you Ctrl-click to open in a new tab. You have to click, see the data, go back, sort again, verify that it didn’t screw up your filters, re-apply them if it did, click something else, wait for the page to load, and see the data. This makes it hard to compare data. I often ended up forgetting what I was comparing by the time I navigated the Firebase UI.

Fire Firebase控制台中的某些屏幕不允许您按住Ctrl键单击以在新选项卡中打开。 您必须单击，查看数据，返回，再次排序，确认它没有弄乱您的过滤器，如果确实没有过滤，请重新应用它们，单击其他内容，等待页面加载，然后查看数据。 这使得很难比较数据。 我常常最终忘记在浏览Firebase UI时正在比较的内容。

⦿ Firebase supports what it calls user properties. They’re independent of any specific event. Think of them as global variables logged to the server. For example, in a camera app, you could have one numPhotosTaken. But this doesn’t work — user properties can only be of string type, so are unsuitable for numeric data.

⦿Firebase支持所谓的用户属性。 它们独立于任何特定事件。 将它们视为记录到服务器的全局变量。 例如，在相机应用程序中，您可以拥有一个numPhotosTaken。 但这是行不通的-用户属性只能是字符串类型，因此不适用于数字数据。

⦿ The Firebase Analytics console doesn’t let you see a graph filtered by event parameters. For example, say you have an e-commerce site, and an order_placed event, and you want a graph of people who placed orders above some threshold. But you can’t do this. Firebase Analytics doesn’t let you see a custom graph. You have to switch to another tool (BigQuery), wrestle with its cognitive overhead (see below), and do a query SELECT * FROM order_placed WHERE amount > 100. Then you need to export the data to a Google Sheet. Then draw a graph using Sheets. This friction is significant enough that you often end up not doing it, so you make decisions without data or with stale data, which defeats the point of using analytics in the first place. Not to mention that our designer, who doesn’t know SQL, was disempowered from getting the data he needs to design better.

base Firebase Analytics控制台不允许您查看按事件参数过滤的图形。 例如，假设您有一个电子商务网站和一个order_placed事件，并且想要一张将订单数超过某个阈值的人的图表。 但是你不能这样做。 Firebase Analytics不允许您查看自定义图形。 您必须切换到另一个工具(BigQuery)，努力解决它的认知开销(请参见下文)，然后执行SELECT * FROM order_placed WHERE amount> 100的查询。然后，您需要将数据导出到Google表格。 然后使用表格绘制图形。 这种摩擦非常严重，以至于您常常最终不这样做，因此您在没有数据或有陈旧数据的情况下做出决策，这首先使使用分析成为现实。 更不用说我们的设计师，他不懂SQL，无法获得他需要更好设计的数据。

⦿ Not only can’t you define custom graphs, but you can’t customse the home screen of Firebase Analytics to show graphs that would otherwise require multiple steps of navigation to reach. For example, for a camera app, the north star metric is photos taken. I had a photo_taken event, and wanted to add its graph to the home screen of Firebase Analytics, so it’s available at a glance. But it’s not customisable. I also wanted to remove some graphs from the home screen, like number of users, since it’s a vanity metric, and putting vanity metrics in your face draws your attention to them, which is the exact opposite of what you should be doing. Unfortunately, neither adding graphs to the home screen nor removing them is supported.

⦿您不仅不能定义自定义图形，而且无法自定义Firebase Analytics的主屏幕来显示图形，否则这些图形将需要多个导航步骤才能到达。 例如，对于相机应用程序，北极星指标是所拍摄的照片。 我有一个photo_taken事件，想将其图形添加到Firebase Analytics的主屏幕，因此一目了然。 但这不是可定制的。 我还想从主屏幕上删除一些图表，例如用户数，因为这是一种虚荣度指标，将虚荣度指标放在脸上会引起您的注意，这与您应该做的完全相反。 不幸的是，既不支持将图形添加到主屏幕，也不能删除它们。

⦿ Firebase Analytics’s retention metrics are useless for the same reason — for a camera app, retention should be defined as what fraction of people who took a photo in one month took a photo in the next. For a messaging app, retention is what fraction of people who sent or received a message this month did so the next. For no product should retention be measured based on people who merely opened the app, as Firebase does.

⦿由于相同的原因，Firebase Analytics的保留指标没有用-对于相机应用程序，保留率应定义为一个月内拍摄照片的人中下一个月拍摄照片的比例。 对于消息传递应用程序，保留率是本月发送或接收消息的人中下一部分这样做的比例。 因为任何产品都不能像Firebase那样根据仅打开应用程序的人员来衡量保留率。

⦿ The Firebase console lets you define custom audiences based on user properties, such as paying users. But only data logged after the audience is defined is counted towards the audience, which produces the wrong answers when you do your analysis. And you don’t even know this unless you suspect it and go around digging for it. This also makes custom audiences useless for a situation when you’re doing some analysis, and want to define a custom audience and see how many are in that audience. Why else would you define a custom audience?

Fire Firebase控制台可让您根据用户属性(例如付费用户)定义自定义受众。 但是，只有在定义了受众之后才记录的数据才计入受众，这会在您进行分析时产生错误的答案。 除非您怀疑它，然后四处挖掘，否则您甚至都不知道。 当您进行某些分析并想要定义一个自定义受众并查看该受众中有多少人时，这也使自定义受众无法使用。 为什么还要定义自定义受众？

⦿ Firebase Analytics is buggy. For example, a field that’s supposed to represent the first time the user opened the app had two different values for 0.6% of my users. How can anyone open the app twice, both the first time? This doesn’t inspire confidence that it’s processing my data correctly.

base Firebase Analytics有问题。 例如，应该代表用户首次打开应用程序的字段对于我的0.6％用户具有两个不同的值 。 任何人都如何第一次打开该应用程序两次？ 这不会激发人们对其正确处理数据的信心。

⦿ Firebase is a Google product and so using it is a business risk. In my case, Google’s systems couldn’t charge my card, that too for 1 paise (< 1 cent). Using a card from another bank didn’t work, neither did paying manually using the console. Google blamed me for them not being able to charge any of my cards, and threatened to delete my account, with nobody available to talk to to sort it out, of course.

⦿Firebase是Google产品，因此使用它存在商业风险。 就我而言，Google的系统无法为我的卡收费，收费标准为1派斯(<1美分)。 使用另一家银行的卡无效，也无法使用控制台手动付款。 Google责怪我，因为他们无法从我的任何卡中扣款，并扬言要删除我的帐户，当然没有人可以讨论解决该问题。

BigQuery的问题 (Problems with BigQuery)

⦿ Firebase Analytics exports to BigQuery, which offers a powerful SQL interface, but querying it is too complex, because the data is not modeled as you’d expect in SQL, with each field becoming a column, so that you can do, for example, WHERE amount > 1000 AND delivery_type = “Express”. Instead, multiple (key, value) pairs are shoved into one value as an array type. Yes, SQL apparently supports an ARRAY datatype. To work around this, you have to do complex, unintuitive stuff like UNNEST. I ended up having to write some 300-line SQL queries, which are a complete waste of time. Instead, Firebase Analytics should export its data to a weakly typed NoSQL database that lets different rows have different columns. Then we’ll be able to write intuitive, straightforward SQL queries like amount > 1000 AND delivery_type = “Express”.

⦿Firebase Analytics导出到BigQuery，BigQuery提供了强大SQL接口，但是查询起来太复杂了，因为数据没有按照您在SQL中期望的那样建模，每个字段都变成一列，因此您可以执行此操作，金额> 1000 AND delivery_type =“快递”。 而是将多个(键，值)对推入一个值作为数组类型。 是的，SQL显然支持ARRAY数据类型。 要解决此问题，您必须做一些复杂，不直观的事情，例如UNNEST。 我最终不得不写一些300行SQL查询，这完全是浪费时间。 相反，Firebase Analytics应该将其数据导出到弱类型的NoSQL数据库，该数据库允许不同的行具有不同的列。 然后，我们将能够编写直观，直接SQL查询，例如，数量> 1000 AND delivery_type =“ Express”。

⦿ The export schema also means that if you mis-spell a field name, like amuont instead of amount, you won’t get an error. You’ll get zero results, leading you to the wrong conclusion. With normal SQL, you’ll get an error saying that there’s no column named amuont.

⦿导出模式还意味着，如果您拼写错误的字段名称(例如amuont)而不是数量，则不会出现错误。 您将得到零结果，从而导致错误的结论。 使用普通SQL，您会收到一条错误消息，指出没有名为amuont的列。

⦿ If you want to query with a comparison, like WHERE amount > 1000 in the previous example, you can’t do it directly. You have to figure out what data type it is and write something like amount.int_value > 1000 or amount.double_value > 1000. This is not ideal — you should focus on your logic, not technical trivia. This has also resulted in wrong results, say when a data type accidentally changed in the code but we forgot to update our query. I realised only after a week that I was acting on incorrect data. If Firebase had just let me write amount > 1000, this wouldn’t have happened. While we’re at it, the logged data has a field float_value but even if you log a float, it gets logged as a double, so any query of the form amount.float_value > 1000 will have zero results.

⦿如果要进行比较查询，例如上一个示例中WHERE数量> 1000，则无法直接进行查询。 您必须弄清楚它是什么数据类型，然后编写诸如amount.int_value> 1000或amount.double_value> 1000之类的东西。这不是理想的选择-您应该专注于逻辑，而不是技术琐事。 这也导致了错误的结果，例如，当代码中的数据类型意外更改但我们忘记更新查询时。 一周后，我才意识到我在处理错误的数据。 如果Firebase只是让我写的金额> 1000，就不会发生这种情况。 当我们使用它时，记录的数据具有一个float_value字段，但是即使您记录一个float，它也会被记录为双精度，因此任何金额为amount.float_value> 1000的查询都将得到零结果。

⦿ BigQuery’s export options don’t work. You are locked into Google.

⦿BigQuery的导出选项无效。 您已锁定Google。

结论 (Conclusion)

I would not use Firebase Analytics for my next project [2]. It’s a tool built without care, without sufficient respect for users’ needs and workflows. I’d look for another analytics service. I don’t mind using Firebase’s BaaS, and I might use Firebase Analytics in the context of that, but I would not use Firebase Analytics if I were looking for an analytics service.

我不会在下一个项目[2]中使用Firebase Analytics。 它是一种无需精心构建的工具，没有充分尊重用户的需求和工作流程。 我会寻找另一个分析服务。 我不介意使用Firebase的BaaS，在这种情况下我可能会使用Firebase Analytics，但是如果我正在寻找分析服务，则不会使用Firebase Analytics。

[1] Another way to disable Firebase in local builds is to change the bundle ID in Git to something else. For example, if your app is com.mycompany.Product, change the bundle ID to com.mycompany.DevProduct and commit the change to Git. That way, when anyone checks out the code from Git and runs locally, Firebase Analytics will disable itself.

[1]在本地版本中禁用Firebase的另一种方法是将Git中的捆绑包ID更改为其他名称。 例如，如果您的应用程序是com.mycompany.Product，请将捆绑包ID更改为com.mycompany.DevProduct，然后将更改提交给Git。 这样，当任何人从Git签出代码并在本地运行时，Firebase Analytics便会自行禁用。

This approach isn’t enough, because you can test in-app purchases only with the correct bundle ID. And, even otherwise, you can’t test analytics changes you make.

这种方法还不够，因为您只能使用正确的捆绑软件ID测试应用内购买。 而且，即使否则，您也无法测试所做的分析更改。

[2] There are a couple more issues that aren’t Firebase’s fault, but which you still need to keep in mind to get the right results:

[2]还有其他一些不是Firebase的问题，但您仍然需要牢记这些以获得正确的结果：

Firebase Analytics tries to log the LTV, but on iOS, it doesn’t include paid up front, because iOS offers no API to query how much the user paid before installing the app. If you have a paid up front app, the LTV is logged as zero. Or in a paymium app where the user buys the app for $7 and then makes an in-app purchase for $2, the LTV is logged as $2.

Firebase Analytics尝试记录LTV，但在iOS上，它不包括预付费，因为iOS没有提供API来查询用户在安装应用之前支付了多少费用。 如果您有付费的前期应用程序，则LTV将记录为零。 或在付费应用中，用户以7美元的价格购买该应用，然后以2美元的价格进行应用内购买，则LTV将记录为2美元。

BigQuery does offer less than and greater than operators for strings, but they don’t work for version numbers like 1.19, because lexicographically it’s < 1.2.

BigQuery确实为字符串提供了小于和大于的运算符，但它们不适用于1.19之类的版本号，因为按字典顺序，它小于1.2。

These aren’t Firebase’s fault, but something that can trip you, so you have to keep these in mind.

这些不是Firebase的错，而是会使您绊倒的事情，因此您必须牢记这些。

翻译自: https://medium.com/@karti/why-i-wouldnt-use-firebase-analytics-in-my-next-project-cdef1644bb48

firebase分析