General rules for fullscreen ads integration: Difference between revisions

From Documentation
Jump to navigation Jump to search
(Created page with "==Fullscreen ads== *The "Double Click" serving algorithm uses a prioritisation model and acts in the present. An earlier decision as to whether an ad booking should be served...")
 
No edit summary
Line 14: Line 14:
*The start page may not be displayed until the preloading ad has been manually closed (per Close Button) or automatically closed by the ad itself (autoclose timeout).
*The start page may not be displayed until the preloading ad has been manually closed (per Close Button) or automatically closed by the ad itself (autoclose timeout).
*In the unlikely event that the ad server cannot send an answer (server failure), the app should load the start page. In order to do this, however, it must wait for a time buffer in order to give the server the option of answering in case there is a poor data connection (recommended: 10s)
*In the unlikely event that the ad server cannot send an answer (server failure), the app should load the start page. In order to do this, however, it must wait for a time buffer in order to give the server the option of answering in case there is a poor data connection (recommended: 10s)
[[de:Grundsätzliche Regeln und Hinweise zum Einbau von Fullscreen-Anzeigen]]

Revision as of 12:35, 11 November 2021

Fullscreen ads

  • The "Double Click" serving algorithm uses a prioritisation model and acts in the present. An earlier decision as to whether an ad booking should be served may already be outdated just a few milliseconds later. It is therefore not possible to determine in advance (e.g. during the app start), whether an ad position is occupied at a later point in time.
  • Timing of the ad requests must be such that an ad has a high contact potential. In the case of swipeable fullscreen ads, they should be sent 1-2 pages before the position and not directly upon the start of the app.
  • The app must use the manual impression counting feature and should perform one-time impression tracking as soon as 1 pixel of the ad is visible. Renewed swiping over the ad must not result in renewed impression tracking.
  • Loaded ads remain in the output. Renewed swiping over the position should not prompt a renewed ad request.
  • The app must not crash due to lack of memory if an ad is being loaded. If necessary, the memory management must remove positions that have already been seen from the memory and, in this event, re-request the positions upon renewed swipe over the position. A re-loaded add must then naturally once again track the impression manually (see above).
  • The app must expand the ad container to display size (see documentation for methods). The ad contained in the Web view reacts passively to the subsequent resize event and adapts to the ad container.
  • Where possible, the app should not overlay the ad and should mask out the status bar of the operating system on the ad page to ensure that 100% of the screen can be used for the advertising.
  • In the ad integration phase before going live, we insert test bookings in all positions. If all necessary parameters (creative sizes, keywords and ad unit) have been correctly entered, the positive feedback will take the form of a test ad returned by the ad server.
  • Correct creative-sizes, keywords and ad unit are necessary for the display of a (test) booking. If the ad server supplies a negative answer ("no ad to show"), there is no booking for the combination of creative size, keyword and ad unit. This may be due to false configuration in the app or in the booking (if the app configuration is correct).

Preloading ad

  • To be served during the splash screen
  • The start page may not be displayed until the preloading ad has been manually closed (per Close Button) or automatically closed by the ad itself (autoclose timeout).
  • In the unlikely event that the ad server cannot send an answer (server failure), the app should load the start page. In order to do this, however, it must wait for a time buffer in order to give the server the option of answering in case there is a poor data connection (recommended: 10s)