Apsalar Debuts New Postback Management System to Ensure Maximum Postback Accuracy and Speed of Delivery


We’re pleased to announce that Apsalar has developed and deployed an entirely new postback management system to raise the standard in the mobile marketing measurement category by ensuring maximum accuracy and speed.

The new system addresses both the profound complexities of delivering accurate and timely information to clients and partners, and the constant growth of both the number and types of data that need to be posted back.

A Little Background on Postbacks

Postbacks are a key way that clients and partners optimize marketing programs. As an attribution platform, it is our most important responsibility to ensure that we precisely track consumer signals, and give credit to the source that actually drove the action. In-app marketing, the most common sources are major media properties like Facebook and Google, as well as more than 1,000 ad networks, affiliate platforms, and APKs. We do this using postbacks, which are basically outbound API calls we make to partners, as opposed to the inbound API calls coming from our SDK or our API-integrated clients.

Clients and sources rely on postbacks to pay for performance and to optimize the programs designed to derive maximum installs and ROI. Sound relatively straightforward? It isn’t.

Some of the biggest challenges of the postback ecosystem are:

  • Processing postbacks is a tremendous volume challenge. We need to deliver accurate information billions of times every day.
  • They need to be delivered as close as possible to real-time
  • They implement often complex macros and other conditional logic so that measurement and automated optimization can take place
  • Different media sources have different systems and need data parsed and organized in different ways
  • Some of the largest partners in the industry – like Facebook, Google, and Twitter, have their own sets of contractual requirements. These can demand any or all of the following: user privacy protections, data segregation and data retention limits.
  • They need to comply with regulatory standards and commitments made to bodies like the US Federal Trade Commission (FTC) and the General Data Protection Regulation of the EU.
  • Cloud computing issues. The massive cloud computing services like AWS and those from Google and Microsoft are extremely popular – with clients, partners, and even our competitors. But occasional instability and performance issues can result in additional complications for postbacks. That’s one reason why we have our own servers and work with a cloud access security broker – to deliver more consistent performance and a higher degree of data security.
  • They need to function when delays caused by Internet instability, partner data stacks, and other delaying issues require that we hold a postback until all parties have delivered relevant data.

Another major challenge is that not all relevant data is automatically delivered to an attribution provider. For some sources, we must ping a series of partners after an install to determine when and if marketing on their platforms “touched” these users.

While we wait for a response to such a ping, it’s important that we not send a postback that will need to be rescinded later. Finally, an attribution platform must be constantly expanding its capacity to deal with the massive growth inherent in the mobile marketing industry, and in its own growth in client count.

From Old to New System

When we built our first postback system, we used a programming language called Python, which is known for simplicity, clarity and readability. But as both the volumes of postbacks grew and the variety of integrations increased, our Python platform struggled with volume during peaks of global usage. Without getting too much into detail, the system reached finite limits of throughput and would then begin to cause delays in postback delivery.

Over the last two years, we had made incremental changes in the platform and made major hardware purchases to address the growth in “normal” postback volumes. But peaks caused occasional temporary delays which could be a source of frustration to some clients and partners. One client, in particular, decided to move on from Apsalar as a result of these temporary delays. For us, the loss of a client is a big deal. In fact, any client dissatisfaction is a big deal for us. The business statistic we’re proudest of is our tiny churn rate.

Our completely rearchitected system will help ensure that our client satisfaction remains high.

Which brings us to today. Our new postback system is built in Go, a programming language developed by Google, and a new database system called Citus DB 5. Citus is a distributed database that makes accessing and processing data far faster than our previous systems.

Speed, accuracy, and scale have all dramatically increased. In a recent test, speed for critical postback tasks increased more than 40X. Perhaps even more importantly, the speed and flexibility of the new system, coupled with a new postback queueing capability that ensures we receive and process all signals from media sources before we deliver postbacks, helped address the persistent industry challenge of rescinded and duplicated postbacks.

Scale has also been addressed. We can now process postback volumes many times higher than the highest peaks we have ever experienced. And the structure of the system enables us to add hardware seamlessly –ahead of new client implementations so that our capacity remains higher than necessary.

We can now state confidently that we are more than ready for the increasing demands and postback volumes. We’re ready for unprecedented levels of scale. It’s something that we can discuss in greater detail with clients and prospects. In fact, it’s something we encourage companies to ask Apsalar, and our competitors, about as part of their due diligence processes.

We’re extremely proud of the team that made this complete redo of the postback system possible. They achieved this key milestone – all while making changes to the old system so that we could handle potential postback spikes while we created the new system. Most of all, we’re immensely happy to be able to deliver a new standard of accuracy, timeliness and capacity to our clients.



Share Button