Importing from Google Ads, and what the import breaks

Microsoft's Google Ads import guide describes a job rather than a one-off copy. You get an import credential ID that links your Google and Microsoft user credentials, you choose the Google account and optionally specific campaigns, you choose import options, and then you schedule it. The documentation states that the API supports import from one Google Ads account to one Microsoft Advertising account.

The schedule options are Auto, Now, Once, Daily, Weekly and Monthly. Auto means Microsoft chooses the cadence. Most agencies I have seen set Weekly and never look at it again, which is where the trouble starts, because a scheduled import is a standing instruction to keep making your Microsoft account resemble your Google account.

That is a reasonable default if the two channels are meant to be identical. It is a bad default the moment you start optimising them separately, and nobody sends you a note on the day that becomes true.

The import guide is explicit that each import credential ID is provisioned for one Microsoft Advertising user and is only valid for importing into ad accounts under one manager account. It also states that changing your Google account password does not invalidate it, but that revoking the BingAdsImport App permission does.

Read that table as an offboarding checklist. The person whose credentials the import runs under is a single point of failure, and the failure is silent: a scheduled import that can no longer authenticate does not phone anybody, it just stops matching Google. Six weeks later the Microsoft account is running last quarter's structure.

If your agency rotates staff, tie the credential to a role account that survives a departure, and put a check on the import results in the same place you check anything else that runs unattended. The reasoning is identical to alerting on campaign anomalies before a human notices them.

The GoogleImportOption object lets you customise the job. Three examples from the documentation are worth knowing by name. DeleteRemovedEntities makes the import delete things that were removed on the Google side. AdjustmentForCampaignBudgets applies a percentage change, so setting it to 25 imports budgets 25 percent higher than Google. UpdateCampaignBudgets set to false leaves existing Microsoft budgets alone.

That budget adjustment option deserves a sentence of arithmetic rather than a shrug. If a Google campaign runs a 200 dollar daily budget and you import at an adjustment of 25, the Microsoft campaign gets 250. Microsoft calculates the monthly limit from the daily budget, and its budget guide gives the recalculation formula: month-to-date spend plus the daily budget multiplied by days remaining including today. So a mid-month budget change does not simply reset the month, it splices onto what you have already spent.

Now the part that is not optional. The import guide states that there is no option to exclude future supported entities from scheduled imports, and gives a worked example: once Microsoft supports a new extension type generally, all current and future scheduled imports will include it until users opt out.

Sit with that. A scheduled import is not a fixed contract, it is a subscription to whatever Microsoft decides to import next. The entity type that arrives in your account nine months from now was never approved by anyone, and it will not appear in your change history as a decision.

The most expensive class of import failure is not a missing entity, it is one that transfers perfectly and then resolves to garbage. Tracking templates are the standard example.

Microsoft's URL tracking guide states plainly that Microsoft Advertising does not validate whether custom parameters exist, and that if your tracking template references custom parameters that are not defined, the landing page URL will include the key and value placeholders without substitution. The example given uses a template with season and promocode custom parameters, and the resulting URL contains the literal braces.

So a Google account with custom parameters set at the account level will import its templates cleanly, and every click will land on a URL containing unresolved placeholder text. Your analytics will record traffic to URLs that were never intended to exist, your campaign attribution will bucket it as unclassified, and the ads will keep serving because nothing is technically broken.

The same guide notes that tracking templates at lower levels override higher ones, that the template is capped at 2,048 characters including the protocol, and that it must begin with http, https, or one of the landing page URL tags. Check those three things on the first import, not the fifth. This is exactly the kind of drift that a URL taxonomy designed to survive scale is meant to prevent.

Google accounts routinely exceed things Microsoft caps. The entity limits page states that each ad group or campaign can contain up to 20,000 negative keywords, that a maximum of 20 negative keyword lists are allowed per account, and that each list can contain up to 5,000 shared negative keywords. It also caps campaign to negative keyword list associations at 50,000 per account, and works the example: five lists across ten thousand campaigns means you cannot add a sixth list to any campaign.

Keyword text is capped at 100 characters. Campaign names at 400. Ad group names at 256 and they must be unique among active ad groups within the campaign. Each account can hold 10,000 campaigns and each campaign 20,000 ad groups.

None of those numbers are hard to clear on a normal account. All of them are easy to clear on a large one, and a partly-clipped import is more dangerous than a failed one, because the campaign exists, spends, and is missing exactly the exclusions you built over three years. If you have inherited a mature negative keyword strategy, verify the count on the Microsoft side rather than assuming the list came with it.

Microsoft says this itself, in the plainest language in the guide: not all information will be imported, and after you import you should review your campaigns and add the missing information back. That sentence is a work item, not a disclaimer.

The mechanism for finding what was dropped exists. Import results are retrievable per job, and there is an operation that returns a mapping of your source entity identifiers to Microsoft entity identifiers, which is the only reliable way to answer the question of whether a specific Google campaign made it across and what it became. If you are already building against the platform, this is one of the better arguments for going as far as an API integration rather than a manual workflow.

My rule with a client is simple. The first import is a draft, not a launch. Nothing goes live until somebody has diffed the entity counts by type, opened three tracking templates and clicked them, and confirmed a conversion goal is attached to every campaign that will use an automated bid strategy.

That review takes an afternoon. Skipping it is how a channel spends a quarter on a structure that nobody chose. On the self storage engagement the cost per acquisition moved once the account stopped inheriting a structure and started reflecting how the business actually sold, and an unreviewed import is inheritance by another name. When a Microsoft account has been running on autopilot imports for a year, the honest starting point is an audit that separates what was imported from what was decided.