Structure: Tracking services

default and tracking service level purple supports various docid 3ofsgplkna2zz3rzik3fg offered by third party manufacturers this leads to the need for the individual tracking services to be configured specifically for each service the reasons include various apis of the sdks different need for events and attributes per tracking service various apis of the sdks each tracking service offers a native sdk, which is integrated into the purple app the apis of the integrated sdks are basically similar, but are still very different this means that, for example, an event must be configured differently for different tracking services different need for events and attributes per tracking service for their desired use cases, a purple customer uses the corresponding tracking services that best support these use cases it can happen that a tracking service only supports a subset of the purple tracking functionality and, for example, only view events can be configured, or a tracking service is used exclusively for tracking purchases, in order to create reports and thus only purchase events need to be configured for this tracking service but now lets start with the structure! basic structure the top level configures the tracking services level and is divided into a " default " section and a separate section for each integrated docid 28levq2nvel a perh1rd this division can be seen in the figure on the right shared "default" section the " default " section represents the fallback solution if no specific configurations exist for integrated tracking services and is always contained in the " tracking config jso n" file this means that this " default " section can serve as a common configuration basis, but only makes sense in certain constellations of tracking services fallback solution for example, if an event "a" is fired for firebase, then it is first checked whether firebase has a config for this event "a" if the config is missing for firebase, it is checked in the default area whether it is available specific tracking services sections the configuration of a tracking service is added with its own section this section begins with a unique " tracking service key " under which the specific tracker configuration takes place the respective " tracking service key " of the various tracking services can be found in the technical descriptions of the individual trackers these technical descriptions of the tracking services can be found in the docid 3ofsgplkna2zz3rzik3fg chapter example an example of an extensive configuration on the top level might look like the figure on the right there you will see the " default " section and the sections for these tracking services adjust airship chartbeat cleverpush firebase tracking config json example code { "default" { }, "adjust" { }, "airship" { }, "chartbeat" { }, "cleverpush" { }, "firebase" { } }