#docs #api #Headlinedocs, Docs, Signals
A Signal is the representation of one event happening in one instance of your app. Here is an overview of its properties.
Signals are an indication that an event happened in your app, which is used by a user. Signals consist of these parts:
- Signal Type – A string that indicates which kind of event happened.
In this case we’ll use
applicationDidFinishLaunching, but it can be
pizzaModeActivated(I totally love that last one!)
- User Identifer – A string that identifies your user.
This can be an email address or a username, or a random ID that you generate once and store somewhere. It should always be the same for all the signals you send from a certain instance of the app. If you don’t supply a user identifier,
TelemetryManagerwill generate one for you.
- A Metadata Payload – Metadata is a dictionary
[String: String]of additional data about your app that might be interesting to analyze.
TelemetryManagerwill always add the user’s OS Version, Platform, Build Number and App Version to the metadata, but you can specify additional info like,
numberOfEntriesInDatabase(an int cast to string) or
pizzaModeAnchoviesEnabled(a Boolean cast to string).
As TelemetryDeck is an analytics software, it analyzes events that occur in your apps’ life cycles. In TelemetryDeck, these events are called Signals. You can think about them like this: An event occurs, prompting your app to send a signal to the TelemetryDeck server. Through aggregation and statistical analysis, your Insights can then extract meaningful data out of the set of signals you have received.
Here is an example signal:
"systemVersion": "iOS 14.4.2",
Signals always have a type. This is a short string that describes the event that caused the signal to be sent. It is recommended to use short, camel-cased half-sentences like these:
When you’re setting up your Insights later, you’ll be able to filter by Signal Type. This is
Signals have a
clientUser property, which stores a string. All signals with the same client user property will be assumed to originate from the same user.
By default, the client user will be a UUID, usually supplied by the devices
identifierForVendor method. But you can overwrite this by supplying your own client user identifier: If you’d rather not track users at all, you can pass an empty string instead. This will effectively disable user counting, but you can still count sessions and signals, and get a good idea of your user base this way.
The TelemetryDeck client library will hash any value saved into this property before sending it to the server. In addition, the server will also hash any client user value again, just to be extra sure. We really do not want to know your users’ email addresses!
Signals have a metadata payload dictionary that contains things like platform, os version, and any data you throw in there. This is highly useful for filtering and aggregation insights.
The default client library will automatically send a base payload with these keys:
You can add any additional keys and values, or overwrite existing ones. For example, it might be a good idea to send your application’s settings with each call. This way, you’ll get a good overview of which percentage of your users have a certain feature enabled, and which configurations deserve the most effort from you.
Signals have a “created at” property that is set to the time (in UTC) when the signal was received on the server. This allows you to group them by time.
These are not implemented yet, but in future versions, the signal API will also accept these properties:
- Session ID, so you can count sessions and session length
- Numerical Metrics, so you can show, for example, a graph of the average number of items in your users’ databases