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):

BUNTE-DoubleClick-Native-Ads-Without-IFRAME-Mobile

BUNTE-DFP-Native-No-Iframe-Desktop

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

DoubleClick_for_Publishers_-_Creative_Detail

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.

<script>
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//
},false);
</script>

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

fields

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.

<script>
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>' +
'</div>';
</script>

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

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 BUNTE.de

Germany’s leading people news website BUNTE.de (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

bunte-de-headless-cms-setup

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.

Q&A

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 BUNTE.de 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:

headless_cms_-_Erkunden_-_Google_Trends

 

So who is doing that all?

The great team below 🙂

BUNTE.de IT Team

 

Image is licensed under CC BY 2.0

 

 

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 BUNTE.de, 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.

BUNTE.de App Home

BUNTE.de App Article

BUNTE.de App Embed

BUNTE.de 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 BUNTE.de 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 BUNTE.de 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.

reactive-nativingitup-png-800x600_q96

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.


TL;DR

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)

 

 

Tech Tools used at BUNTE.de

So what kind of tools are people at BUNTE.de 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.

https://www.flickr.com/photos/47292975@N05/4398070128/

cc licenced https://www.flickr.com/photos/47292975@N05/4398070128/

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

Development

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

Organisation

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

Communication

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