Around the time of iOS 14 (Sept 2020), Apple and other companies started to crack down hard on user privacy and data use. Handing over your user’s keys to 3rd party analytics provider started to look like a bad idea for two reasons:
For these reasons, we began to experiment with handling simple analytics in-house. We set up an API and stored the data with Google Big Query.
We store the following data in each request:
| Name | Description |
|---|---|
| user_agent | The browsers user agent string |
| platform | The Platform the request came from e.g. Windows |
| os | The OS the request came from e.g. iOS 16.3.1 |
| browser | The specific browser e.g. Mobile Safari UI/WKWebView |
| browser_version | Version of the browser e.g. 16.3.1 |
| environment | a string representing the env of your app e.g. staging or production |
| app_name | Unique name for the app |
| app_version | Version number of the app the request came from |
| app_hash | Hash of the last commit |
| user_id | (Optional) a unique string or number to represent the user |
| client_ip | The IP the request came from |
| global_sequence | This incrementing number will help detect the sequence of requests in a single users session |
| event_time | The time the request was made |
Analytics data can be stored in two tables:
This table stores a row for each visit a user makes to an app route. As well as the standard Data outlined above. Visits also store:
| Name | Description |
|---|---|
| title | A unique string to represent the route the user has visited |
| name | A full URL including route/query params |
| visit_sequence | This incrementing number will help detect the sequence of visit requests in a single users session |
This table stores a row each time the user triggers an event of some kind in your app. This may be:
As well as the standard Data outlined above. Events also store:
| Name | Description |
|---|---|
| name | A unique string to represent the event e.g. login. success |
| data | (optional) A JSON object containing any data related to the event |
| event_sequence | This incrementing number will help detect the sequence of event requests in a single users session |
The API for collection data contains two endpoints. Check out the existing ember-analytic-sauce for a guide on how you could use the API in other frameworks.
Here’s an example of a request made from the sauce cupboard to log a visit
POST https://analytics.sauce.construction/visits
Data:
{
"environment": "production",
"appName": "cupboard",
"appVersion": "2.1.1",
"appHash": "43f9f138",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36",
"sessionId": "i6j27xs3ndui1x9injpd",
"userId": null,
"viewSequence": 1,
"globalSequence": 1,
"name": "/",
"title": "internal.index"
}
Here’s an example of a request made from the sauce cupboards to log a search event
POST https://analytics.sauce.construction/events
{
"environment":"production",
"appName":"cupboard",
"appVersion":"2.1.1",
"appHash":"43f9f138",
"userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36",
"sessionId":"i6j27xs3ndui1x9injpd",
"userId":null,
"viewSequence":1,
"globalSequence":4,
"name":"cupboard.search",
"title":"internal.index",
"data":{
"term":"til",
"results":[
"Anti-Bribery Policy",
"Today I Learnt",
...
],
"number":51
}
}
The easiest way to analyse collected analytics is via Google Looker Studio (Formally Data Studio).
Ensure you filter results by app_name and environment and away you go! Reports can be locked down to certain user accounts and shared/embedded in portals and cms platforms.
When connecting a data source in Looker Studio select BigQuery > SauceAnalytics-Prod
Check out this example of an analytics dashboard with Google Looker Studio.
Developer, Designer, UX Zealot. Ember & Tailwind