I have an application that is available on multiple platforms:
web
desktop/native (Windows / macOS)
phone/tablet (Android / iOS)
The front-end of all platforms is shared. It's built with React.
Right now, all analytics data is sent to the same account/property/view.
I want to have precise data about the usage and user technology (operative systems, versions, etc) of my desktop apps. Because, if I see the operative systems or global usage, I don't know which data is from the web application and which data is from the desktop/native app.
I would like to do the same for the mobile apps, because I want to have views with only data from the native apps, and not from users accessing my web app on mobile devices.
But, I would also want to have an overall view, so that I can see the global usage without having to sum the values from different views.
What is the best way to split the data and achieve what I want/need?
Thank you.
Unfortunately this is not available in Google Analytics you would have to use Google Analytics Reporting API to merge the data.
If you are using Google Analytics 360 (Premium), you have the option to use Roll Up property. Even then you won't be able to use Firebase Analytics in Roll Up properties.
Roll-Up Reporting aggregates data from multiple Analytics properties and lets you see that data together in the same reports.
Roll-Up Reporting comprises two types of properties:
Source Properties: Individual Analytics properties that include data from a single site, app, or internet-connected device.
Roll-Up Properties: Properties that serve as aggregators of the data from multiple Source Properties.
Official guide to Roll Up Properties
Related
I have 2 different Play Console accounts and each have a Stories app in them. Currently both of them are linked to same Firebase account (i.e. same database). I want to ask if this is ok or should I make a separate Firebase project for each app?
The short answer is, it depends.
If the two apps are identical or closely related (eg. an admin-only app that controls the flow of the client app), then yes, you'll want to configure both apps to use the same Firebase project so that they both have access to the same data.
Using the same Firebase project in multiple apps is pretty common, especially in the scenario outlined above as well as deploying to multiple platforms. Take, for example, an app that you have deployed on the web, iOS, as well as Android. These apps run on different platforms, but they are essentially the exact same app, with the exact same functionality. You don't want to be maintaining multiple projects containing duplicate data, so it's a good idea to connect different versions of the same app to the same Firebase project.
On the other hand, if these apps are not related at all (eg a quiz game and a social media app), then it doesn't make sense for them to be using the same Firebase project as the two apps are completely separate from one another. In this scenario, using the same project would lead to disorganized data, as well as making it potentially more difficult to secure and query as the apps have separate functions, and thus separate logic to control the flow of data.
It sounds like your use case falls into the first category. You have the same app on multiple Play Console accounts. You probably want the data to remain consistent between them, so you'd want to use a single Firebase project.
All my app's data is stored in Firebase. I'd like to build some reports with my data that aren't necessarily accessible through the web/app front-end. I don't see any good options for this in the Console. Has anyone found a good reporting solution for Firebase? I am looking for something like Crystal Reports or just an easy way to render Firebase data based on a query.
Thanks,
Rima.
I found a issue with the solution above. Firebase stores its data in JSON format, which cannot be consumed by solutions such as BigQuery, because it is expecting JSONL format and you get an error. It beats me why Google are not providing an elegant solution when integrating between two of their products, but I believe they have something planned.
Firebase does not have any "built-in" reporting tools other than the defined querying APIs.
If your database is small, you dump the JSON from the Firebase Console and then manually run analysis on it.
If your database is large, you can upgrade to the Flame or Blaze plans and sign up for daily private backups. This will create a JSON dump in the background without affecting your database performance and store it in the cloud. You could then use tools to grab that dump and perform advanced reporting on it.
1) Via BigQuery
Official Docs:
https://cloud.google.com/bigquery/docs/loading-data-cloud-firestore
Codelab Walkthrough:
https://codelabs.developers.google.com/codelabs/modern-data-pipeline-firestore-bigquery-dataflow-templates/index.html?index=..%2F..next17
Connect whatever BI tool you want to BigQuery. Google Data Studio is
free as is Metabase. Almost every Enterprise BI tool has a BigQuery
connector.
From https://www.reddit.com/r/Firebase/comments/arps42/reportingbi_tools_and_firestore/
2) Via "Custom Data Sources"
Cloud Firestore (and probably Realtime-Db) has a RESTFUL API. Many popular reporting tools support "custom", "restful", "ajax", and/or "HTTP" sources.
You should search your favorite reporting tools, and internet search accordingly.
I can see that Stimulsoft seems to support custom/RESTFUL sources. A PowerBI data connector seems to provide a lot of latitude - https://github.com/Microsoft/DataConnectors
Of course, this means that you need to create several data sources, and they probably won't be as optimised as a built-in source type. For example, the report engine probably won't know how to translate any front-end UI filters into custom-source query filters. Perhaps some platforms support the ability for you to create your own adaptors.
Google just released Firebase 2.0.
It seems they are completely separate platforms.
Firebase: https://www.firebase.com/
Firebase 2.0: https://firebase.google.com/
APIs are also different.
Firebase: https://www.firebase.com/docs/web/api/
Firebase 2.0: https://firebase.google.com/docs/reference/js/#firebase
Could someone explain the differences in the core concepts on both mobile and web?
I've been building an app using old Firebase.
Should I change my codes to use Firebase 2.0?
The new version of Firebase is the same platform - it just adds a whole range of new features, so the big change to the core concepts is an expansion of what you can do.
The Realtime Database offers the same functionality as before, but with a refreshed API and a new console. You can keep using the same approach and data model as before, and the API changes are largely cosmetic (renaming to be consistent with the newer features).
Authentication is pretty similar, but it has been expanded to include new features like account linking and customizable emails. You should be able to upgrade your application to the new SDKs and console pretty easily: take a look at our migration guides for Android, iOS and the web.
You can import your project at any time. Your applications and the existing SDKs will continue to work. You can then update your code when you are ready to use some of the new Firebase features in your application.
The new concepts are really around the new features:
Analytics is a new mobile-first analytics product that gives free and unlimited event reporting, and allows building audiences which can be used in many other services.
Storage allows you to store and serve user-generated content, such as photos or videos.
Remote Config allows you to change the behavior and appearance of your app without publishing an app update.
Cloud Messaging is a cross-platform messaging solution that lets you reliably deliver messages and notifications at no cost. Notifications gives you a tool in the Firebase Console to send re-engagement messages easily.
Crash Reporting lets you collect crash data from your Android and iOS apps, to find and fix problems more quickly.
Dynamic Links are smart URLs that dynamically change behavior to provide the best experience across different platforms. They allow you to use deep links that survive app installs on Android and iOS.
Several existing Google products have been integrated into Firebase as well
Invites replaced AppInvites, giving easy way to sending personalized email and SMS invitations. App Indexing gets your app into Google search.
Firebase now also integrates with AdWords to let you target ad campaigns with Analytics audiences, and AdMob to automatically track in-app ad effectiveness.
Its a lot of new features, but you don't have to try them all at once! Once you upgrade, its straightforward to pick and choose.
We are planning to develop a new application that should offer:
Android-capable
Turn by turn with voice navigation
Offline maps (and perhaps routing?)
Satellite maps
Truck issues
As fas as I can see, all of the requirements (but the offline routing) is included in different Here Maps developer plans. Nevertheless, I still have some questions:
On their web (https://developer.here.com/plans/api/consumer-mapping), there are two main divisions (API plan and Mobile SDS plans). Which one is better for me and what is the difference?. I mean, it seems clear that I should go for the mobile plans, but not sure if this will be limiting my development in the future.
There appear no pricing options for the Mobile SDKs. We are planning to make the app available to our customers on a free basis and they will be charged for enhanced services. But seeing that API plans are based on a volume basis... how does the mobile plans work? (does it have any cost depending on the number of transactions too?).
Finally, customized POI are the main advantage of our app and is closed to other users (will no be made publicly available). Does the Here api include the option to add our POIs coming from another (ous) database on the fly?.
Thanks in advance,
Jose.
Turn by turn guidance will be only available via the (Premium) MobileSDK. Via REST APIs you can get routing, but not TbT voice guidance. Also Offline is only avaiulable via the Premium MobileSDK. Beside this, the native MobileSDK offers native vectorbased map rendering, when you use the REST APIs you would need to use the raster tiles. So in a nutshell: if you target Mobiles, you should definitely go with the MobileSDK. If you need any feature that's only available via web APIs (platform extensions, isoline routing, and some more), you can still combine these web APIs with the MobileSDK.
Pricing depends on your usecases, so you should discuss your usecase with HERe Sales: https://developer.here.com/contact-us?interest=mobile-sdk#contact-sales
Customized POIs is quite general, but of course you can load datasets from your servers and show them as POIs on the map, but you could also use the Platform Extension CLE, that also allows you to search within your dataset and is seamless integrated in the MobileSDK already.
I have a mobile apps that i applied my google analytics track IDs but when i create the google analytics app profiles i initially choose web app instead of mobile app. while exploring around the settings, I could not find a switch to convert it into mobile app. I have more than 10 app with different google analytics track id, so i don't think creating new profile is great solution, there might be switch to change it to mobile app.
Someone out there might have encounter this situation. please help.
Solution:
What i did to solved this was create a new App, same name with the web one, then set it to mobile and then delete the web app.
The accepted answer is actually the incorrect. Specially if you have a existing web profile which as lots of historical data. Here is how to solve this by keeping your existing web property.
You add a profile view on your existing Web Property which can be a Mobile Ap Profile. https://support.google.com/analytics/answer/1009714?hl=en
The big clue came from this Upgrade to Universal Analytics post https://developers.google.com/analytics/devguides/collection/upgrade/reference/mobile-sdk
"To get access to new app reports and features, you will need to upgrade to v2.x or higher of the SDK and create at least one app view (profile) in your reports to view the data. Any new data sent from your app will only be available in this new app view (profile), while your old data will continue to be available in the original web view (profile). Learn more about the latest version of the SDK for Android or iOS."
There is currently no way to change the type of tracking after the profile is created. You will have to create new profile IDs and update the apps.