Ready, Set… Adobe Launch & AppsFlyer

Published in

AppsFlyer Engineering

6 min readApr 2, 2019

Recently Adobe invited us to contribute an AppsFlyer extension to their new marketing cloud platform — Adobe Launch, with an important part of the new solution including an SDK that supports external extension contributions to the marketplace. Native integration with the Adobe SDK would enable an improved user experience for AppsFlyer and Adobe users alike, by simplifying the integration with a diversity of web apps and tools from a single platform.

Since AppsFlyer sees this kind of ecosystem integration as key to excellent customer experience, we quickly got to work on building our extension. AppsFlyer released its Adobe Launch SDK Extension for mobile analytics within a few weeks — integrating AppsFlyer’s mobile attribution capabilities with Adobe Experience Cloud.

Analytics, not only “crash” analytics

In order to have some context about what this means, we’ll first start by describing quickly what an analytics SDK actually does, and why it was important for us to integrate natively with Adobe’s Launch SDK. In this landscape, there are many analytics SDKs out there; some are used to dispatch information about stability and performance, while others are used for measuring installs or campaign efficiency.

What they all have in common is that they all dispatch events that users can then measure (and then make intelligent business / development decisions). To get as holistic a picture as possible — it’s a common practice for customers to implement multiple analytics / attribution SDKs within the same codebase.

Example of a in-app event that invoked with the AppsFlyer SDK:

This is great for the customer who can aggregate analytics data from multiple sources and optimize their marketing as a result, but on the development and integration side this can cause conflicts due to the large number of integrations and even the amount of code, as well as API calls these analytics SDKs fire off individually and collectively. This means that for any given event — there are often times as many as 10 API calls.

AppsFlyer Engineering is always hiring, just like our product’s always-on, 24/7 SLAs. >> Learn More

That is why many applications, Adobe included, have chosen the architecture design of having one core analytics hub that dispatches an event and then fires off a single API call to all the analytics SDKs integrated — and they dispatch a similar/matching event to their applications. This analytics core is essentially two-way, as it also mediates between the events sent from the SDKs to the analytics core.

The AppsFlyer Launch extension consists of iOS and Android SDKs (written in Java and Objective-C respectively), as well as a CDN-delivered configuration JSON that enables you to receive the configurations without any extra API calls.

These event-binding libraries enable attribution and session measurement, in-app event measurement, SDK callbacks (attribution data), and the ability to collect Adobe IDs.

The AppsFlyer Adobe Launch SDK extension is also configurable via a Launch UI dashboard where you enter the config info & functionality. Once the configuration data is saved, its settings will be passed to your extension via CDN, and they are then later passed from the Adobe Launch SDK to the AppsFlyer Extension during runtime. This streamlines initialization without having to use programmatic API calls, which are provided by the CDN.

One major advantage with Adobe’s Experience Platform (unlike similar solutions) is that the “configuration” GUI web-view, is in full control of the Extension Developer. An additional component that allows the creation of a configurable web dashboard, that can later be used by the end-user to set any setting, property or configuration needed for the Mobile SDK, or the “extended” SDK.

This makes it possible for anyone developing on this platform to do so independently — including adding any configuration or parameter — without having to wait for Adobe product managers and engineers. This is excellent for velocity — as you can make changes, and immediately deploy them to production without having to wait for any approvals on the Adobe side. All this makes it possible to scale the widget we currently have to a pretty complex configuration dashboard, given the need.

When creating the GUI web-view, you will need Node.js (for Adobe’s tools and sandbox), while the code itself is in JavaScript and HTML/CSS. There are also some packaging tools that you can then use to package your web extension, as well as sandboxing tools to test your code locally. The packaging tools are useful for later applying automation, since you can release using Node (NPM) or using an API. You can find the list of tools at the bottom under resources.

This is a code snippet of the web-view:

This custom web-view is ultimately served by the code below.

The properties that are set in the web-view are later delivered by the Adobe CDN to the clients “SharedState” listener.

An Event Driven System

Another interesting aspect of Adobe’s system design is that many “core” components of the former Adobe Mobile SDK are now broken out to “native” extensions, for example: the Adobe Analytics Extension or the Adobe Audience manager.

This creates an “events driven system” where all extensions or “modules” can send/receive events to a “shared state”, which means they can all dispatch and receive data, and bind events between the different modules and extensions — or even just “listen” to the data. The shared state is also used for obtaining the configuration JSON from the Adobe CDN, and other “local” configurations and properties, either directly or can be updated by other extensions.

While we were building a mobile extension, Adobe’s Launch SDK can also be leveraged for web extensions, and this is the flow we used and adapted to be able to build the mobile extension’s flow, since the mobile extension documentation was still being updated when we were writing the extension.

Summing it Up

This extension simplifies the experience for both Adobe and AppsFlyer users, so it was important for us to be integrated as early as possible. The design enables fast integration of various web apps and tools (for example AdWords integration or the Adobe TypeKit font library), while leveraging AppsFlyer’s mobile and web attribution natively.

Give it a test drive, and let us know what you think. Feel free to provide us with feedback or comments, we’re always happy to improve the experience.