Here’s how we reduced our CPM by ~25%

Here is the story of how we beefed up our performance marketing muscle through accurate conversion signals and saved lakhs each day.

Everyone knows a marathon is 26.2 miles but did you know how this specific measurement came to be?

The legend goes that Philippides, a messenger, was sent from the Battle of Marathon to the greek council to announce “We are winners!” Unfortunately, having run the whole distance of 26.2 miles to deliver the news, Philippides collapsed and died immediately after. If only there was, dare I say it, an app or system that allowed the Greeks to communicate directly without the foot messenger. 🏃‍♂️😵

We empathize, because a few months ago we too were dealing with a communication issue of our own — albeit a 21st-century version of it.

The realization: Our performance marketing system didn’t have enough juice to tweak our performance marketing efforts.

The solution: We needed to boost its efficiency + Build a better communication link with our ad platforms.

And thus began our marathon of finding an effective route!

Before we move into the thick of things, let’s revisit the basics.

What is performance marketing?

Performance marketing is a results-driven digital marketing strategy that is crucial for companies looking to reach an audience at scale. The metrics tracked in performance marketing are attributable and measurable.

As an E-commerce platform, we need to identify and acquire users who will not only install the app but also take specific actions such as “add to cart” and make a purchase. With performance marketing, driven by platforms like Facebook and Google, we can track these actions.

Imagine, a user takes an action on the app by adding an item from Meesho’s feed to their cart. We would then create an event “Add to Cart” against that action. Our performance marketing partner will then receive this event signal from us, whenever a user adds a product to their cart. This helps us target other users, with similar persona, who are likely to download the app and add product to the cart as well.

Obviously, this information is critical for running effective ad campaigns. It is also supercritical that this information is relayed back to the ad platform accurately and punctually.

Here’s what didn’t work for us:

1. Unaccounted for data: We applied the magic sauce in real-time. Meaning, that some events were not tracked in case a query failed or timed out due to the complexity or volume. We were processing billions of rows every single day (Billions of rows processed every day). Doing it in real-time also meant debugging these processes or resending the lost events, which was impossible.
2. Delayed and irrelevant data: Until very recently, we were unable to employ server-to-server (S-2-S) integration because the APIs weren’t exposed earlier and the functionality was only available through app SDK. Our legacy system had an unavoidable dependency on the Meesho app and Ad platform’s SDK for sending the events to our Ad platforms. A user after taking an action (event), had to start another session on the app for the events to be picked up for processing. Due to this, if a user was opening the app after 10 days, there would be an extremely high delay in processing the signals, which made them less relevant and useful.

How we solved these problems

We figured out an optimum way of processing event signals through an S2S design where Meesho servers would directly talk to the ad platform servers without any app dependency. This helped us resolve four problems at once:

1. Since we are sending events directly from the backend, app reopening rates don’t affect our event count.
2. If a new event is introduced, we don’t need to wait for app updates and app adoption to change campaign objectives. This is possible because we are processing and sending ~100% of the events via the backend directly at full capacity from the get-go.
3. Since we don’t depend on a Blackbox (Ad platform SDKs) in our events architecture; we can now monitor our events and create actionable alerts. This leads to shorter TATs in resolving issues with events.
4. Our events pipeline is now more robust and scalable
5. Since we have moved to Kafka (Queue Manager) and Redis (Data Source), the data is more real-time. Moreover, we can process more data and we can scale it as and when needed. Redis helps us with our de-dup logic, because of which, if we somehow fail to send events, we can now resend the missed ones and backfill them in case of any failures.
6. We do not rely on MySQL anymore. Earlier there were occasions where Input/Output Operations Per Second (IOPS) used to increase, which was a bottleneck, leading to loss of events in case of timeout.

The Impact

App-independency has increased our event accuracy by ~40%. This, in turn, has resulted in more efficient ad campaign performance and reduced our cost per impression (CPM) by ~25%. We also ended up saving a few lakh rupees per day.

So now, Philippides does not run a marathon but video calls the greek council with any battle-related updates 🤳🏛!

Think you have the chops to take up these projects? Do you want to work with people building for a billion Indians? Sprint over to our careers website and apply now.