Search
Clear search
Close search
Google apps
Main menu

Transition your site to DFP tags

If your website is new to ad serving or switching from another ad server to DoubleClick for Publishers, you'll need to add DFP tags to your site. This article provides some best practices for that process. There are two different approaches that we recommend for making the transition:

  • Replacement method: Dynamically remove any ad tags from your previous ad server and add DFP tags.
  • Mirror method: Create mirrored versions of your site, one containing your existing setup, and one containing DFP tags. At the right time, transition your production servers from the old to the new version of your site.

Which method you choose is up to you, depending on the capabilities of your content management system (CMS) and the way you transition campaigns. While these best practices are meant to give you an overview of each method, you should work with your Google contacts, your internal site developers, and your CMS vendor, if necessary, to ensure that you understand all of the implications of the approach you choose and get the details right.

Most DFP implementations use Google Publisher Tags (GPT), which use JavaScript. They're different from many other ad tags in that they have two parts: one that goes in the headers of your webpages, one that goes in the body section. If you use GPT, you'll need to take this two-part structure into account as you design your CMS template.

 

Other DFP implementations use simplified URLs for non-JavaScript environments such as mobile platforms or the Google Mobile Ads SDK for mobile apps. Regardless of which tags you use, the recommendations below are still useful.

Replacement method

This method typically requires that you be able to add tag templates to your production site. We suggest the following workflow:

  1. Add the DFP tag template to your webpage templates.
  2. Identify your legacy ad tag template, if you've been using one.
  3. In a test page, manually or automatically remove any existing ad tags and insert DFP tags.
  4. Validate ad serving and impressions against test campaigns that you set up in DFP.
  5. On the scheduled transition date, manually or automatically remove any existing ad tags and insert DFP tags across the production version of your site. Begin this process in a development environment or test site to make sure that it works correctly. WIthout testing, you run the risk of unexpected results such as incorrect impression counts or page layout issues.
  6. Validate ad serving and impressions against either test campaigns or real campaigns across your website.

Advantage

  • If you're using GPT, the replacement method allows you to perform a soft launch, rolling out GPT to your page headers prior to launch and rolling out the complete GPT section by section rather than across your whole website at once.

Considerations

  • While your pages are in transition, it's best to avoid any other changes to your content or page templates. Otherwise, you run the risk of unintended results.
  • Careful testing is required for all of the different scenarios that can occur during this process, including pages that are in a transitional state.

Mirror method

This method typically requires you to have a development environment that exactly mirrors your production site. You can make changes to your development environment until you're ready to move it to production. At launch, you'll deprecate the original environment and replace it with the updated development environment. We suggest the following workflow:

  1. If you don't already have one, create a development environment that exactly mirrors the production environment in content and layout.
  2. Add DFP tags to the development environment.
  3. Remove any preexisting ad tags from the development environment.
  4. Adjust the content and layout as appropriate for any other systems or page changes that will be going live along with DFP tags.
  5. Validate impressions and ad serving against test campaigns that you set up in DFP.
  6. On the scheduled transition date, switch the development site to production and deprecate your existing production site. Follow your CMS's best practices, which often include switching DNS records, redirect links, and production designations within the CMS.

Advantages

  • If you're migrating to a new CMS, that's a great time to implement DFP tags as part of the migration.
  • You can see how DFP tags and line items render in the development environment, before it goes to production. It gives you a more thorough testing environment, which can provide a greater level of assurance.

Considerations

  • Because the development environment doesn't have regular site traffic prior to launch, it will take DFP seven days to build a baseline for forecasting, and 28 days to build up the data necessary for a full forecasting model. Forecasts during this initial period should be understood as less precise than under normal conditions.
  • You'll need to keep your development environment in exact alignment with your production environment until the transition. If you're making updates to your production site while the transition is in process, you'll need to ensure that the changes are reflected in the test environment as well.
Was this article helpful?
How can we improve it?