Stampen Media embraces failure on its way to innovating its digital advertising

By Håkan Hamrin

Stampen Media

Gothenburg, Sweden


The digital advertising business is rapidly changing. As a publisher, you need to adapt to new challenges.

One current challenge is that the CPM (cost per 1,000 impressions) on a lot of our traffic is lower. The death of third-party cookies is redrawing the map for actors in ad businesses and lowering CPM.

We know from several sources that 40% of the traffic isn’t addressed in this way. At the same time, buyers still use the third-party cookie for targeting, but that inventory is shrinking and we cannot serve buyers with the type of audiences they are asking to meet.

To provide advertisers with the greatest likelihood of reaching potential customers, media companies must adapt.
To provide advertisers with the greatest likelihood of reaching potential customers, media companies must adapt.

We can wait for the demand side to change, or we can try things on our side.

At Stampen Media, we have had to adapt. As head of programmatic, it is my job to explore where we have new revenue models. To do that successfully, I believe we have to try new techniques. Having the opportunity to do this numerous times throughout the years, I think the following is inevitable:

  1. You will always fail.
  2. You will fail again.
  3. It will always take longer than you estimated to get the results you need.
  4. Those that succeed in minimising bias will find new business models first.

Let’s look at these learnings through the lens of an innovation project at Stampen Media has been working on with several of our suppliers.

The terminology

Before diving into our situation, it is helpful to define some of the key terms involved.

  • PubCommon ID is a privacy-centric, first-party cookie solution built with consumer privacy in mind. It does not sync IDs across domains, so the IDs your domain generates are yours to share with whom you choose.

  • ID5 is a universal ID used by some buyers. It is one of the identifiers available in prebid.

  • First-party data is the data collected on your sites or by your visitors. Third-party data is data collected elsewhere. Your data is only first-party data if you use it on your sites. If you use it on other sites, it is third-party data for that site.

  • A first-party cookie is a cookie (a small textfile set in your browser) set by you on your own sites. A third-party cookie is a cookie set by some other actor.

  • A first-party ID is an ID you have set on your sites. For example, when we set an ID on a visitor on our sites, that is a first party ID. But when a system on our sites is setting its own ID, that is a third-party ID.

Nowadays, a lot of browsers are blocking cookies from third parties to make sure no external parties can use whatever they want on your sites. By using ID solutions, we can let trusted parties act like a first-party ID. This means they can use that ID to set the frequency on an ad campaign or see what audience from our first-party audiences this ID is connected to.

How it started

Our supplier, Adform, released a new technique they call ID Fusion. ID Fusion allows advertisers to bid on impressions based on the publisher’s first-party IDs. The solution is ID agnostic, meaning that, regardless of the ID vendor you use as a publisher, Adform’s demand-side platform (DSP) is capable of bidding and optimising against it, as well as using it for capping frequency.

Since our strategy is to make it easy for buyers to buy our inventory, and to be an early adopter, it was a given we should try this solution.

The first step was to set up a meeting with us, Adform, and our data supplier, Brain. At this point I could not see the full structure of how the thing was going to be built, but given that Brain and Adform felt aligned, all I had to do was lean in because I certainly saw the business opportunities. Little did we know how complicated it was going to be.

The failures

The idea was to send our ID to Adform and let it connect that to ID Fusion. At the time, though, Adform couldn’t receive any ID. So instead of sending the ID from us, they had to set a PubCommon ID. Adform also had to make sure our users had the same PubCommon ID every time. Brain couldn’t send the PubCommon ID itself.

This meant we had to involve another supplier to get this up and running. We reached out to our head bidding supplier, Livewrapped, to see if we could get the company to send the PubCommon ID that was set by Brain. Happily, they could send the PubCommon ID through Prebid, which made it possible for Adform to catch it on its side.

After some weeks, we could actually try with an advertiser. There was absolutely no effect!

What happened? All the players had a look from their side to find the problem. It turned out that it was a two-headed problem: When Adform received IDs, the company looked at them in a set order. First, they looked at ID5, and if there was no ID sent from them, they looked at PubCommon ID, and so on. But we didn’t send any ID from ID5, so why did this happen?

Well, this is almost true. We tested with ID5 through Livewrapped just a little over a year ago. Even if we had stopped that test, there was still an active line for ID5 through Livewrapped, even if it was always empty. So, when ID Fusion got an active ID5 request, it didn’t look at the PubCommon ID.

This had a simple solution, though. We just inactivated ID5 in Livewrapped, which we should have done earlier. The good news was that now it worked with ID Fusion.

I wish that, at this point, we could have carried on, but the truth is it only worked perfectly through Livewrapped. What we saw was that, with deals, most of the requests were sent directly from Adform’s supply-side platform (SSP) to Adform’s DSP. When there was an open auction, there were more requests through Livewrapped. And, when not sent through Livewrapped, there was no first-party ID added in the request.

This resulted in the strange effect that it was easier to buy on our first-party ID via ID Fusion through open auction than through deals. That’s not really what we wanted.

The next step

Knowing that, we took the next step.

One reason we made this through Brain and Livewrapped was that our own development teams were quite occupied with other large projects. It would have taken much more time for our own teams to do this, but now we didn’t have another choice. We needed to make this development ourselves.

Luckily, we now know more about what we are doing. It’s quite easy for us to add the ID in the correct place in the request we make to Adform.

I have also learned a lot about ID connectors. This is important in a world where 40% of Web traffic doesn’t have third-party cookies. We also learned that you need to know what IDs to send and what you don’t send.

Additionally, we realised that working with ID connectors can raise the reach on Safari and Firefox for advertisers. Looking at the numbers from several campaigns over a two month-period, we saw an increase in impressions on Safari from 32% to 48%. Those are good numbers for both us as a publisher and advertisers.

Lesson learned

We failed and it took us way longer than we had planned to execute, but we are early adopters so we have a low threshold.

Most importantly, it was worth the hassle, given that we are interested in exploring the new business models that companies like Adform are moving toward. The fact we take time to innovate today is our best shot at owning a part of tomorrow’s market.

About Håkan Hamrin

By continuing to browse or by clicking “ACCEPT,” you agree to the storing of cookies on your device to enhance your site experience. To learn more about how we use cookies, please see our privacy policy.