Home Why Your Mobile Analytics Kit Wants To Be Open Source

Why Your Mobile Analytics Kit Wants To Be Open Source

Open source is different things to different people: software licensing scheme, business model, development model or community model. However we choose to think about it, though, across the board clever people are using open source to disrupt or change how markets behave.

Therefore, I found it fascinating to sit down recently with a German entrepreneur using an open source approach to disrupting the mobile application market. Paul Müller is the CTO and co-founder of Adeven, a mobile advertising tracking and analytics company based in Berlin that is entering the U.S market to compete with firms like Has Offers, Apsalar, Localytics and Flurry.

At Adeven, Müller has built an open source software development kit (SDK) that is hosted on GitHub. The SDK is used by some of the largest eCommerce and publishing companies in Europe. While relatively new to the U.S. market, Adeven has Fab.com as a client, which boasts 12 million users and a top ranking on Apple’s App Store.

Prior to Adeven, Müller and his team were app developers and publishers at their previous company. They got fed up with poorly written, proprietary SDKs required by third-party analytics and tracking services. Those SDKs crashed their apps and cloaked interactions with user data. The results were poor app performance along with security and privacy risks. The logical conclusion was to build their own SDKs and open source them. 

I spoke to Müller about why open source SDKs can make all the difference in mobile.

ReadWrite: In the Web world, you almost never hear about companies integrating SDKs to measure user behavior. Why are SDKs so critical for this task when it comes to native mobile apps?

Müller: Measuring user activity and reporting it in a relevant fashion to app publishers is far more complicated in mobile than in the Web world. There are two main problems in mobile. The first is defining a session. The second is erratic connectivity with mobile.

At first it was easy to define a session: apps were either on or off and, when the user left the app, the session was closed. When platforms started to support multi-tasking, these status changes became more diffuse. Just because the app is put in the background doesn’t mean that the session is over. Users increasingly flip between different states such as “resume,” “background” and “foreground.” Figuring out what counts as a session has become considerably more chaotic.

Paul Müller

We chose to define a standardized session as a continuous stream of actions and state changes with no more than a 30-minute gap in between. This, of course, requires analytics to gather information on a variety of state changes and events, and keeping these up to date is not a job most developers want to take on by themselves.

ReadWrite: You mentioned a second challenge: connectivity?

Müller: Yes. Mobile network connections are unreliable and sometimes very poor. With package loss and connections to the server dropping more often than we realize, the SDK has to make sure that data actually reaches the server. This includes accounting for data gathered while offline and relaying it when online.

Even when the SDK isn’t fully offline, requests aren’t fire-and-forget: they are sometimes lost and need to be repeated. What if Angry Birds never saw the sessions that happened on the subway? We see up to 20% of all sessions take place offline. So you need an analytics tool that is embedded in the runtime of the app itself that records activity and then sends it up later.

ReadWrite: So why is open source in SDKs so much more important in mobile?

Müller: Because an SDK must be injected into your application codebase, it can dramatically impact stability. If it’s poorly written or uses outdated code, then the SDK may crash your app. That’s about as bad as it gets. If an app crashes once, users get annoyed. If it crashes twice, they could leave and never come back.

Because most mobile app SDKs are compiled binaries and are closed source, there is no way for an app developer to know for sure whether the SDK is the cause of the crash. A developer definitely cannot spot the specific part of the SDK code that may be causing a conflict. With open source SDKs, all of that is possible. You can easily trace a crash back to the offending SDK (apps are often running more than one) and even trace it back to the specific line of code.

ReadWrite: You also have mentioned privacy as another important reason to use open source SDKs.

Müller: Yes, definitely. If the SDK is a black box, then the app developer cannot know what information the SDK is collecting about the app users or how that information is being collected. Yet, it is the app developer who is legally on the hook to comply with all privacy regulations.

Analytics companies that pull data out of apps via an SDK may also be feeding that information to other companies for other purposes. So, for example, your app may be violating the new California privacy standards for “Do Not Track” signaling standards. If you break those rules, either the government or private parties can sue you. If you are using only open source SDKs, then at least you have the option of reviewing the code to see how information gathering and distribution is handled inside the app itself.

ReadWrite: I assume there are other hazards of relying on closed source analytics.

Müller: Definitely. If you are using a mobile tracking service that has a closed-source SDK and you need to request a feature change, you are totally at the mercy of the SDK maker. With an open-source SDK, you can write the code modifications you want, submit a pull request, and probably get someone to at least consider including your code or possibly to give you their blessing to run a slightly forked version.

Also, if you plan to integrate your analytics data with other third-party marketing or revenue optimization tools – particularly using APIs—it’s very helpful for their technology teams to have access to the SDK. With an open source SDK, that’s never an issue because anyone can see the code if they need it.

Paul Müller is the CTO and co-founder of adeven, a mobile advertising tracking and analytics company. Prior to adeven he was the CTO and Managing Director for two companies, rapidrabbit and Müller & Wulff GmbH.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.