How to run fully responsive DoubleClick Native Ads without IFRAMEs

Our marketing & advertisement department recently has been asking for slots to be managed by an adserver on our homepage to run native ads & house campaigns.

This integration should not use typical banner / IAB formats but feel like an integrated part of the website should be manageable using campaigns to track goals like CTR, impressions etc.

Spoiler alert: This is how we serve native ads now (Mobile / Desktop):



And this is all done using DFP and a structured, simple way to deliver and manage these campaigns. See the edit form below.


But this was no super easy task, we had to tweak a few things …

The major drawback of native Ad Support in DoubleClick

DFP is now supporting Custom Native Ads and this seemed to be exactly what we’re looking for.

There is one thing that we’ve stumbled upon pretty soon – all native ads, including custom native formats, are rendering using an IFRAME. This means these ads do not share the styles with the host/parent page and responsiveness is somehow complicated.

You could start adding your own styling to the inline CSS used for native ads but this would be blowing up things.

Our workaround: Use postMessage to pass the final ad content to the parent page for rendering

Our native ad is still living within an IFRAME, but invisible to the end user. All it does is creating the ad content and pass this content (simply a string) to the parent page for rendering (basically add a string to the DOM). This way, the ad really becomes part of the DOM, fully responsive and enjoys the same features as the rest of the page.

So this is how it works:

Preparations on our own website – add message handling / rendering stuff

Prepare the parent page to accept incoming ad content to be rendered

Place a div where you want to have your ad to show up.

<div class="bunte-embed-ad" data-container-ad-unit-id="/23748239/BUNTE_Home_Beauty_Teaser"></div>

The ad-unit-id is holding our Ad Unit ID, this is important as the page has to know where to place the incoming ad string, especially as we have multiple native ad slots on our pages.

The second part is adding the necessary script to handle the incoming ad content string that will be fired from the DFP Native Ad IFRAME back to the parent page (= our own HTML page).

We’ve added this script to our basic utility JavaScript.

var eventMethod = window.addEventListener ? "addEventListener" : "attachEvent";
var eventer = window[eventMethod];
var messageEvent = eventMethod == "attachEvent" ? "onmessage" : "message";

// Listen to message from child window
eventer(messageEvent,function(e) {

var key = e.message ? "message" : "data";
 var data = e[key];

var eventName = data.message || 'ignore';

if (eventName == 'adContentAvailable') {
 console.log( 'ad data available: ', data );
 // replace content 
 $('div,li').filter('[data-container-ad-unit-id="' + data.adUnit + '"]').html( data.content );
 //run function//

The function is doing a pretty simple thing – once a message with the eventName adContentAvailable is available, take the adUnit Parameter of this message (used to identify the Ad Unit / Placement) and add the ad content (data.content) to the markup at that position. Please see the block below (DFP definition) to see how we build this message with the given params.

Proper setup of DFP native ads – post message with ad content to parent page

Field definition example


Nothing groundbreaking here, a title, kicker, image (uploaded by the marketer) and target link.

The custom HTML for our native ad style

The native ad style html will not output anything, but concat a string instead and post this string to the parent for further handling.

var link = '%%CLICK_URL_UNESC%%%%DEST_URL%%';
var content =

'<div class="row">' +
'<div class="col-xs-6 col-sm-12">' +
' <a href="' + link + '" class="channel-item-img">' +
' <img src="[%Image%]" data-src="[%Image%]" alt="Image" width="405" height="225" class="img-responsive">' +
' <span class="tag-photo">[%Tag%]</span>' +
' </a>' +
'</div>' +
'<div class="col-xs-6 col-sm-12">' +
' <h3>' +
' <a href="' + link + '" class="channel-item-subtitle">[%Kicker%]</a>' +
' <a href="' + link + '" class="channel-item-title"> [%Title%] </a>' +
' </h3>' +
'</div>' +

var data = { 'message' : 'adContentAvailable', 'adUnit' : '%%ADUNIT%%', content : content };
parent.postMessage( data ,"*");

The major part of this markup block is about compiling our teaser format markup. This is exactly the same as our other teasers on the website look like. As our ad will be added to the proper placement with the exact same structure, all formatting will automatically apply and fit the ad fully responsive in our environment.

The important part here is the last script block.

The generated string will be passed to the parent page for rendering, adUnit will let the parent page know which Ad Unit we’re talking about there. This string will match the data-container-ad-unit-id property shown above in the markup added to the parent page to place the ad at the correct position.

It’s working – Fully responsive native ads using DFP!

It’s now finally working and editors and marketers are happy to easily serve native ads using DFP campaigns.



Say hi to Carrier – the new headless CMS at

Germany’s leading people news website (30m+ visits/month) is now powered by Carrier, a full featured headless publishing setup with a strong focus on distribution and rendering. This approach called “decoupled” or “headless” enables us to handle content curation & creation independent of content packaging, distribution, syndication, placements etc.

Our editor’s workspace Thunder (Burda’s own Drupal Distribution) is providing the created content via a REST/JSON API and is not involved in any kind of rendering, placements, caching etc. This part is handled by a Custom Java Application called Cockpit. This custom application also enables the editor to send push notifications, manage placements on the website using a micro service called Pilot and many other features.

Carrier components: CMS, Cockpit, Pilot & Rendering


Benefits of a headless CMS setup

There are a couple of good reasons to go headless:

  • Focus on the next business opportunities & challenges
    You need flexibility and clear abstraction to reach your goals, as websites turn into products instead of “CMS projects”.
  • Micro service  architecture with Docker & CI/CD
    Carrier consists of micro services handling different parts of the system. We can now enable/disable/upgrade certain parts without touching the entire system.
  • Simplification of output format management
    This is possible due to the abstraction of the well-structured content and output. Think of using content for e.g. chatbots or Amazon Echo.
  • Substantial frontend rendering performance increase
    The entire markup is now under our control and not a wild mix of script, markup and styling blocks created by multiple modules.
  • Simplified caching layers and no more purging pain
    Our simple caching rules: Pages = 1min, Images + Assets = 8hrs. Simplest Akamai config ever. That’s all, no more Varnish/Purging/Expiry Management.
  • Subjectively: Increase of talent in the team
    The stack is broader and it’s just offering a mix of “sexier” technologies.
  • More stable CMS
    Drupal is focused on content creation/curation and providing this data with a simple REST API just runs smoother than one handling tons of stuff.


Why did you go headless?

Short answer: We’ve been tired of the traditional CMS experience and it’s tradeoffs. When looking for alternatives, the PM and CTO stumbled upon articles on the Washington Post Product BlogSmashing and Vox, got inspired and decided should follow this approach as well.

Long answer: The traditional way of developing websites feels just not right in a world with a growing number of distribution channels, formats etc. A lack of flexibility, poor performance and the missing level of abstraction (“The Story” should be just kept independent of any other aspect) are key topics. And not to forget the pain of having tons of modules in your setup for simple tasks. Want feature A? Sure, it just depends on module B, C with C only working with CMS version x. Plus the need to maintain rather complex caching setups as otherwise your CMS will become unresponsive pretty soon.

What about image management & rendering?

We’re running multiple instances of the amazing Thumbor. Thumbor gets passed information set by the editor in the CMS (Focal Point) to have the correct center for resizing.

What about the performance?

Data sent from the CMS is stored in Redis with maintained relations. Based on that, we can render even complex articles in approx 15 msec.

How is the frontend managed, which libraries do you use?

Our stack is pretty basic – Bootstrap, some custom scripts and a really powerful Google Tag Manager setup. Actually our entire dynamic frontend is managed by GTM including ad rendering, tracking, Recommendation widgets etc. Say goodbye to modules eating attention for tasks which easily can be covered in a few lines JavaScript and a datalayer property.

What about menus, top articles etc? How are they managed?

We’ve cut the pages into parts rendered as individual pieces and stuck them together using good old Apache SSI. The same applies to e.g. the header, all fully managed using the CMS and will be sent to Cockpit via API. Top articles are fetched from Google Analytics on a regular basis, same for trending.

What kind of drawbacks to be expected?

It’s getting complex. You need senior people who have been working with rather complex setups, you need data contracts (using e.g. swagger) and solid end2end tests (read: Selenium, cypress) to make sure the data that is entered at the CMS is properly rendered in all output formats.

What happens exactly when the editor hits the “Publish” button?

Our CMS will ping Cockpit, Cockpit will fetch the data using a REST API, render the article in 8+ formats (web, amp, FB IA, syndication partners, …) and trigger renderings of connected objects (e.g. an image is updated which is part of 10 image galleries which is part of 20 articles). Additionally, updates of various feeds are triggered (Sitemaps, RSS Feeds, Feeds for the App, syndication feeds, Newsletter systems etc). So there’s quite a few things are going on 🙂

How do you deploy a new version?

Jenkins is building the various micro services and pushing a new Docker Container to Amazon ECR and updating ECS.

Does this approach fit for each website?

Definitely not. For smaller websites this is overkill, but you still might want to take a look at e.g. Contentful and it’s middleman connector.

Is this a common trend?

As far as we see almost any huge Publisher is looking closer at that option. Google trend tells us there is growing interest as well:



So who is doing that all?

The great team below 🙂 IT Team


Image is licensed under CC BY 2.0



Introducing Slack at – Bye Bye E-Mail!

10+ CC recipients, unused confluence setups, 10MB+ daily reports killing your Quota, unknown members in your internal Skype groups – sounds familiar?

To solve this issues, we’ve decided to switch the entire internal communication at to Slack. Slack is the new communication hub for all departments including the editorial team, marketing, audience development and our video unit. Our Product & IT team was using Slack already for a while with great success, so we thought it’s time for a big roll out 🙂

Slack CMYK

Why Slack? What’s wrong with Skype and E-Mail?

This was a question, we faced quite a lot of times from team members. And to a certain extend this is true – Skype has group conversations, Email is good enough for one2one communication and WeTransfer can be used to send huge files without any hassles. But let’s face it – it’s such a mess with all these tools and it’s pretty hard to control just about anything regarding access policies, notification management or a structured way of handling the communication.

The top five reasons for us to introduce Slack

  • One Stop Shop for the entire internal & partner conversation
  • Reduce the amount of internal emails and shorten response times
  • Ability to integrate 3rd party services like News Alerts or Reports
  • Clear administrative workflows (like adding a new user)
  • Still feels like a fresh, friendly service and lightweight compared to enterprise solutions

Rollout – Driven by innovation and soft power

We did some planning and introduced Slack by adding one team after the other (e.g. social media → audience dev → video etc). We also created a first set of channels with dedicated purposes. Each team leader was introduced to the service in a short demo session to be the contact person for the entire team. After one week the entire team was boarded, having almost all people installed both the desktop and mobile app.

Guess what – already in the first few days we saw the magic taking off – thousands of messages in the first 48hrs can’t lie 🙂

And of course we’ve also used soft power – internal email wars and Skype have been declared legacy and daily reports are now only available on Slack.

Results of introducing Slack

Since a couple of weeks the entire team is on Slack and we can see an outstanding adoption rate. The important things are happening there, so it’s the place to be. This includes organising the lunch location as well 🙂

We can also see faster developing stories as the time wasted with emails and sending/receiving stuff has been eliminated. Everybody working on a story is also right at the same spot which also helps a lot.

By pushing daily reports directly to Slack we’ve also gained a new level of transparency among the team, everybody is on the same page :).

Third party services / Notifications

One of the outstanding features of Slack is the number of integrated services to push the idea of a one stop information shop.

Here is a non-comprehensive list of what we’ve integrated so far:

  • Custom Alerts for trending stories, User Feedback, CMS Publishing status change etc
  • Spike and other Social Media Monitoring Tools
  • Google Docs – Custom KPI Reports
  • Trello – Project Management
  • JIRA – Software Development
  • Pingdom, AWS CloudWatch, Route53 – Monitoring & Alerts
  • travis/Jenkins – CI Server



So what’s next? We’re planning to attach more custom third party services over time to establish a cockpit for everybody working at

If something important happens, Slack will let you know. Think of a headline that does not perform, a new feedback in the app store or a native campaign that has just reached it’s target.

Welcome to the new collaboration & bot age 🙂

Image CC-licence


Mobile Apps for Publishers – Native, Web or Hybrid?

Apps feel like a ambiguous topic to most Publishers. They serve the most loyal users but with a high price ticket and a lack of flexibility. So what about “Hybrid” apps?

When we started working on the Relaunch of the leading german people news portal, our apps have been put to the test as well. In this post I will cover a few aspects, why we’ve picked React Native as new mobile app platform.

And here are some screenshots of the current beta (iOS): Home – Article – Embeds – Video SDK/Ads. Please note that we did not change the UI of the app in the first release as we focused on the rewrite itself. App Home App Article App Embed App Ads

The Android Beta can already be downloaded here.


The core use cases will define the platform

The platform discussion started with a simple but far-reaching question:

Is is still worth the money and effort to have a native app, or is a Web Container App just about good enough?

To answer this question we did quite some research and prototypes to evaluate our core use cases in addition to compelling technical comparisons out there.

To give you a few examples of core stories:

As a regular visitor and I want to have quick & easy access to my favourite source of celebrity and gossip news. The app should be fast, simple and well designed.

As a product owner, I want my app to drive the user’s stickiness, generate substantial ad revenues and keep the initial and ongoing costs at a low level.

As a developer, I want to maintain an app that’s sharing the common stack of and feels like a native app to provide the best experience.

“Real” Native apps perform best – but what about alternatives?

The outcome of our tests and prototypes was pretty clear – native apps rock when it comes to performance, look and feel. They suck when it comes to flexibility (e.g. embeds) and cause a high level of maintenance. Pure Web Container Apps are very flexible but performance quickly becomes a pain (we even tried Google’s AMP as rendering format) and it just feels not right.

And then there is a third option – Hybrid Apps or platforms compiling JS to native code.

Hybrid: How to gain flexibility and keep the native touch

Hybrid apps are a mix of native and web elements. A tab bar and video player might be a native, UX optimized component but an embed or simple text is rendered using Webviews. Popular frameworks include Titanium (which is a rather cluttered platform), Apache Cordova and the newest kid on the street – Facebook’s React Native.

Facebook’s React Native – the holy grail?

This framework is pretty new but very well designed and – most important – the apps really feel like native regarding the look & feel and performance – simply because they are native!

“Hybrid” as we define it, reflects the mix of React Native and WebViews rendering certain portions of the content.

And this is the Facebook’s definition: With React Native, you don’t build a “mobile web app”, an “HTML5 app”, or a “hybrid app”. You build a real mobile app that’s indistinguishable from an app built using Objective-C or Java. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React.

Of course we had some troubles along the way, especially with the integration of Native SDKs but still the overall experience is really neat.


So why did we go for React Native?

  • Perfect match with our core use cases
    We’re looking for an maintainable way to build apps without the overhead and dedicated resources needed for native apps. Performance is critical but it’s no deal breaker to have slightest delays for some operations.
  • Common code base for both apps
    Easier maintenance, feature consistency among all platforms.
  • Shared Stack Know-How
    The Stack is related to our other environments (JS, CSS) so it feels like home to developers and we can share resources.
  • Native UI/UX
    Platform consistency for a native touch. Just compare scrolling content in a WebContainer app or in ReactNative (60 FPS) – the difference is amazing. Think of Hybrid on steroids.
  • State of the art technology
    Emerging and fast growing technology
  • Extensibility & Flexibility
    Support for native SDKs (e.g. Video Player or Google Tag Manager). We could even migrate crucial parts to our own native components and use JS as controller only.

So is it really the holy grail? In many ways React Native is different from the previous approaches. Facebook is releasing a new version on a monthly basis and the usage in Apps like Facebook Groups, Ad Manager and the “big” FB app is putting the spotlight on this technology. Quite a number of issues still have to be fixed (e.g. interaction with native SDKs, performance tweaks) but – again – it’s incredible given the fact React Native is still at 0.29 when writing this post.


For Publishers with a JSON API and enriched article content, hybrid Apps build with e.g. ReactNative are definitely the recommended way to both provide an outstanding user experience and keep the maintenance/development costs low and the technology stack clean.

Image licence/source (CC)



Impressions of our regular Team Workshop/Update Sessions

At, we have workshops with the entire team on a regular basis. Teams are presenting highlights and lowlights of the last few months, we’re talking about our product & technology roadmap, the overall strategy and goals for the next few months.

A few impressions from our recent session: Team @ Workshop Team @ Workshop


Tech Tools used at

So what kind of tools are people at using? This question sometimes will pop up when chatting with fellows at Burda or mostly in job interviews.

I would say we have a rather simple tool kit for driving our product development and daily operations. Driven by the startup experience of quite a few team members we all love lean and clear solutions without big hassles or overheads.

cc licenced

So this is the typical environment for anyone working in Prod/Tech:


PhpStorm,  Xcode (IDEs), jenkins, codeship (CI), IntelliJ IDEA


JIRA (with Scrum Boards), Confluence (knowledge base, concepts), bitbucket & github (git)


Slack (with 3rd party integrations), Google Hangout (Audio/Video), Skype and Email

Recommended local tools

Skitch (Screenshots), Sketch (UI), Omnigraffle (workflows, rough UI), Textwranger, SequelPro, Cyberduck, Office


Image credits – cc licence


Welcome to BurdaStudios Insights!

Hi there!

The Publishing Industry is under heavy fire. Disruption is taking place in many ways and companies who want to stay alive have to reinvent themselves in almost any aspect. The new DNA consists of  unique & inspiring content, superior data driven services and products people love.

The agenda of Product & IT teams is now filled with platform strategy, customer centric product development, internal process optimizations, data science, syndication, lead & agile methods just to name a few buzz words. All these things also require new management approaches and shape job profiles in many ways.

In this blog we want to provide you with some insights of how we handle all those challenges at BurdaStudios. We will cover our ideas, tools, processes but also our failures and lessons learnt. The main focus will clearly be on, the leading online celebrity & people website in Germany and tracdelight, the leading German Premium Fashion Affiliate Network.

Happy reading 🙂