Connected Devices/Projects/Metrics: Difference between revisions

Jump to navigation Jump to search
→‎Framework Decision: refining the Framework chapter
(→‎Background: adding "Rationale" chapter)
(→‎Framework Decision: refining the Framework chapter)
Line 13: Line 13:
* Visualize the metrics information
* Visualize the metrics information


== Framework Decision ==
== The Framework ==
After studying [https://docs.google.com/spreadsheets/d/1zMgrunttlH0qSr-2qpiIAPb6DPo837V68AGYmJYCPME/edit#gid=0 several third party solutions] the team decided to go for Google Analytics.
After firstly assessing Mozilla Telemetry Pipeline, and later [https://docs.google.com/spreadsheets/d/1zMgrunttlH0qSr-2qpiIAPb6DPo837V68AGYmJYCPME/edit#gid=0 several third party solutions] the team decided to go for Google Analytics (GA) as the Framework for Collecting Metrics. The key reasons are:
* It fits our needs both in terms of metric collection and visualization
* Technical Fit: Google Analytics meets our needs both in terms of metric collections, accessing to raw data and visualizing it.
* GA has been already vetted in Mozilla and we are already paying for a premium service
* Adoption: The integration of GA with CD trains seemed to be the faster-one (e.g. in one day we managed to get some results in one of the trains: SmartHome).
* Implementing GA will be faster and less effort than adapting the Mozilla telemetry pipeline for use with CD projects
* Legally/Commercially: GA has been already vetted in Mozilla and we are already paying for a premium service
   
   
We have been working in three major activities:
It’s important to clarify that the framework is using the [https://developers.google.com/analytics/devguides/collection/protocol/v1/ Google Analytics Measurement Protocol] that is more appropriate for IoT projects than Classic Google Analytics which is more e-Commerce related. The metrics are stored by GA in a Google BigQuery instance.
* Implementing a library for Rust and JS that simplifies the adoption of Google Analytics by the trains
* Documenting the parameters that can be used for collection of events
* Evaluating reporting/visualization tools to ensure that metric data can be easily analyzed by the trains


The target of this is ensuring all the trains send information in a consistent way and dashboards/reporting are consistent cross-train.
The Data can be later on retrieved via the [https://www.google.com/analytics/360-suite/data-studio/ Google Analytics Console] that is very convenient to check if the data is being received and getting simple charts about the trains (e.g. how many users are currently “live”?).


=== Project Status and CD metrics integration ===
In addition to the Google Analytics Console, the trains could also use Google Analytics Data Studio.
The CD Metrics Project uses Google Analytics capabilities as a collection point for the various trains/projects. We are using the Google Analytics Measurement Protocol that is more appropriate for IoT projects than Classic Google Analytics which is more e-Commerce related.


CD Metrics is just a framework but the usage of the data is up to trains. Once data is collected, there are several visualization options available for them. Have a look at them together with the steps to follow to integrate CD Metrics in your train in our [[Connected_Devices/Projects/Metrics/Integration|'''CD Metrics Integration''']] page
Furthermore, [https://www.periscopedata.com/ Periscope] can be used to formulate SQL queries against the BigQuery Database. Periscope is a third party toolmthat can be used to get more sophisticated reports. Additional tools exist to create reports, that could be used by the CD trains, if they deemed they are necessary.


== Program Status ==
== Program Status ==
Confirmed users
1,225

edits

Navigation menu