Fix Microsoft Advertising Scripts: Setup & Common Errors

This sounds obvious, but getting into the Scripts editor the right way matters, especially if you're managing multiple accounts. I've seen people waste an hour debugging a script that was running against the wrong account entirely.

Here's the exact navigation path: sign in at ads.microsoft.com, then look at the global navigation bar running across the very top of the page. Click Tools, then select Scripts from the dropdown. You should land on the Scripts management page where you'll see a list of any existing scripts and a Create script button in the upper right.

If you're working with a single advertiser account, you're in the right place. Click Create script, click on the default "Untitled script" text at the top of the editor panel, and rename it to something meaningful before you do anything else. This saves confusion later when you have multiple scripts and can't remember which one does what.

If you need to run scripts across multiple accounts you manage, this is critical: you must access the Scripts editor from a manager account (previously called a Super Admin or agency account). If you navigate to Scripts while inside a sub-account, you'll only ever be able to access that one account's data. The multi-account AccountsApp object is only available when you're operating from a manager account context. Check the account name shown in the top-left corner of the interface, it should show your manager account name, not an individual advertiser name.

After creating your script, you'll see a code editor panel on the left and a Logs/Preview panel on the right. The two buttons you'll use most are Preview and Run script now. If everything is set up correctly, clicking Preview will execute the script in a read-only simulation mode and output results to the Logs tab, without modifying any live campaign data.

One of the biggest sources of confusion with Microsoft Advertising Scripts is misunderstanding what Preview actually does, and doesn't do. Let me clear this up because it directly affects whether your troubleshooting gives you accurate feedback.

Preview mode executes your script's read operations and logs output exactly as it would in a live run. So if your script calls AdsApp.keywords() and logs keyword data, Preview will show you that data accurately. This is genuinely useful for testing data retrieval logic without risk.

Here's the catch: write operations behave differently in Preview. If your script calls build() to create an ad group, or changes a bid, or pauses a campaign, Preview will simulate running those operations and report success in the logs, but the actual changes are not committed to your account. This is intentional and protective, but it means you can't fully verify that a write operation works until you run it for real.

Microsoft's documentation is explicit that preview mode has limitations for scripts that modify data. Always run write-heavy scripts in Preview first to catch JavaScript errors and logic bugs, then switch to Run script now for the live execution. Never go straight to a live run on a write script you haven't tested.

To check script output after either mode: click the Logs tab in the right panel. Anything you sent to Logger.log() in your code appears here. If the Logs tab is empty after a run, it means either your script has a syntax error that prevented execution, or your script ran but had no Logger.log() calls, which is a common mistake when adapting sample code. Add a simple Logger.log("Script started"); as the very first line of your main() function to confirm execution every time.

The AdsApp object is the entry point for everything in Microsoft Advertising Scripts single-account access. Every entity type, campaigns, ad groups, keywords, ads, has a corresponding selector method on AdsApp. Calling AdsApp.adGroups() gives you a selector for all ad groups; AdsApp.keywords() gives you all keywords; and so on.

The selector itself doesn't fetch data. It just defines what you want. You chain filter methods onto it (withCondition(), withIds(), forDateRange()) and then call .get() at the end to actually retrieve an iterator. This distinction trips up a lot of people. The selector is the query definition; the iterator is the result set. Don't call .get() until you've specified all your filters.

For withCondition() errors, the most common mistake is mismatching the column name or operator. The condition string uses specific column names that don't always match what you see in the UI. For example, filtering ad groups by campaign name uses CampaignName, not Campaign or campaign_name. Here's the correct pattern:

var campaignName = 'My Campaign';
var iterator = AdsApp.adGroups()
  .withCondition(`CampaignName = '${campaignName}'`)
  .get();

If you're chaining multiple conditions, each one is added as an independent .withCondition() call. Multiple conditions are treated as AND logic, only entities matching all conditions are returned. If you accidentally put two conditions in one string separated by AND, you'll get unpredictable results. Keep them separate:

var iterator = AdsApp.adGroups()
  .withCondition(`CampaignName = '${campaignName}'`)
  .withCondition(`Name = '${adGroupName}'`)
  .get();

If you want to get a specific entity by its numeric ID rather than filtering by name, use .withIds() instead. Pass IDs as strings inside an array. This is faster and more reliable than name-based filtering when you have the ID available.

Once your selector is configured correctly, calling .get() returns an iterator. The iterator is how you actually loop through and work with your entities. The pattern is always the same:

while (iterator.hasNext()) {
  var adGroup = iterator.next();
  // work with adGroup here
}

hasNext() returns true if there's another entity to retrieve; next() advances the cursor and returns the entity object. If your while loop never executes, your selector returned zero results, which means your filter conditions eliminated everything, or the date range is missing, or you're looking at an account with no matching entities.

The most painful iterator issue is getting performance stats. When you call adGroup.getStats() inside the loop and see zeros for everything, you've almost certainly forgotten to chain .forDateRange() onto the selector before calling .get(). The date range must be declared at the selector level, not after the fact. Here's the correct structure:

var iterator = AdsApp.adGroups()
  .forDateRange('LAST_30_DAYS')
  .withCondition(`CampaignName = '${campaignName}'`)
  .get();

while (iterator.hasNext()) {
  var adGroup = iterator.next();
  var stats = adGroup.getStats();
  Logger.log(adGroup.getName() + ": " + stats.getImpressions() + " impressions");
}

You can use predefined string literals like 'LAST_WEEK', 'LAST_MONTH', 'LAST_30_DAYS', or 'YESTERDAY' for the date range. If you need a custom range, pass an object with year, month, and day properties for both start and end dates. Month is numeric (6 = June) and there's no zero-padding needed. This is also required any time your withCondition() filter references a performance column like Ctr, Clicks, or Cost, leaving out the date range when filtering on performance data will cause silent failures.

Another iterator gotcha: the .withLimit() method caps how many entities the iterator returns. The sample code in Microsoft's Getting Started docs uses .withLimit(15) to get 15 keywords. If you're building production scripts and copying that sample, remove or adjust the limit, otherwise you'll wonder why your script only processes a fraction of your account's entities.

Adding new entities through Microsoft Advertising Scripts, new ad groups, keywords, ads, uses a builder pattern that's different from the selector/iterator flow you use for reading data. Getting this wrong is a common source of "my script ran but nothing changed" complaints.

The builder lives on the parent object. To add an ad group, you first need a campaign object, then call .newAdGroupBuilder() on it. You can't call a builder from AdsApp directly. Here's the sequence: get the campaign through a selector, then build the child entity:

var campaignIterator = AdsApp.campaigns()
  .withCondition(`Name = 'My Campaign'`)
  .get();

if (campaignIterator.hasNext()) {
  var campaign = campaignIterator.next();
  var adGroupOperation = campaign.newAdGroupBuilder()
    .withName("My New Ad Group")
    .withStatus('ENABLED')
    .withBiddingStrategy('MANUAL_CPC')
    .withCpc(1.5)
    .build();
}

The .build() method returns an operation object, not the entity itself. This is a common misunderstanding. To check whether the entity was actually created successfully, and to get the newly created entity back for further use, you need to call methods on the operation object:

if (adGroupOperation.isSuccessful()) {
  var newAdGroup = adGroupOperation.getResult();
  Logger.log("Created: " + newAdGroup.getName());
} else {
  var errors = adGroupOperation.getErrors();
  Logger.log("Failed: " + errors);
}

If you skip checking isSuccessful(), a failed build silently does nothing and your script logs no error. This is exactly why "I ran the script and nothing happened" is so common, the build failed, but without error checking in place, you never find out. Always wrap build operations in a success check. In Preview mode, isSuccessful() will return true even though no entity was committed, so you must use Run script now for final verification that a builder operation actually works end-to-end in your live account.