Google Tag

Every Google Ads account has exactly one Google tag (AW-<id>). Its website conversion actions are the events a site fires through it.

Read the tag

Zernio exposes that tag under the platform-neutral tracking tags API on your googleads connection. You can:

• read its code and conversion labels
• switch conversion tracking on
• set auto-tagging
• create and edit its website conversion actions
• see conversion counts
• install it on a connected Shopify store or WordPress site

This is the site tag. The campaign's click-URL tracking template is a different thing, on URL tracking tags.

GET /v1/accounts/{accountId}/tracking-tags lists one tag per customer on the connection. It does not call Google, so it costs no quota.

GET .../tracking-tags/{tagId} reads the tag's settings and conversion actions, and adds the gtag.js base code. tagId is the customer id (see Ids).

import Zernio from '@zernio/node';

const zernio = new Zernio();

const { data } = await zernio.trackingtags.getTrackingTag({
  path: { accountId: '66b2e19d8c3f5a7e9d0b1c2d', tagId: '1234567890' }
});

Response (200):

{
  "platform": "googleads",
  "tag": {
    "id": "1234567890",
    "name": "Google tag (Acme Store)",
    "platform": "googleads",
    "kind": "tag",
    "status": "active",
    "ownerAdAccountId": "1234567890",
    "siteTagId": "AW-16799533812",
    "code": "<!-- Google tag (gtag.js) -->\n<script async src=\"https://www.googletagmanager.com/gtag/js?id=AW-16799533812\"></script>...",
    "events": [
      {
        "id": "7012345678",
        "name": "Purchase",
        "type": "PURCHASE",
        "status": "ENABLED",
        "siteEventId": "AbC-D_efG123hIjK",
        "siteEvent": "purchase"
      }
    ]
  }
}

status is inactive while the account does not track conversions.

Reads go through Zernio's Google read cache, so repeated reads do not call Google each time.

Ids

events holds the account's WEBPAGE conversion actions. GA4-imported and upload actions are not fired from a page.

On GET .../tracking-tags/{tagId} only enabled ones appear. The /events list also returns removed (archived) ones.

siteEvent is set when the action's category maps to a storefront event:

Conversion counts

GET .../tracking-tags/{tagId}/stats returns one row per conversion action with conversionActionId, conversionActionName, category, allConversions and allConversionsValue.

The window defaults to the last 30 days. startTime and endTime (Unix seconds) are applied as whole days in the account's time zone, so an edge can shift by a day.

aggregation is Meta only and answers 400 here.

Switch the tag on and set auto-tagging

POST /v1/accounts/{accountId}/tracking-tags with adAccountId (the customer id) and name is idempotent on Google.

An account that already tracks conversions gets its existing tag back, and nothing is created.

Otherwise Zernio creates a WEBPAGE conversion action named name (category DEFAULT) and returns the tag. That action is what turns Google's conversion tracking on.

PATCH .../tracking-tags/{tagId} takes autoTagging (true or false), for gclid auto-tagging. It is the only tag-level setting the Google Ads API lets Zernio write. Every other tag field answers 400.

Conversion events

The tag's events are its WEBPAGE conversion actions, managed on /tracking-tags/{tagId}/events:

const { data: created } = await zernio.trackingtags.createTrackingTagEvent({
  path: { accountId: '66b2e19d8c3f5a7e9d0b1c2d', tagId: '1234567890' },
  body: { name: 'Add to cart', siteEvent: 'add_to_cart', countingType: 'every', primary: false }
});

Response (201), with the conversion label read back from Google:

{
  "platform": "googleads",
  "event": {
    "id": "7012345699",
    "name": "Add to cart",
    "type": "ADD_TO_CART",
    "status": "ENABLED",
    "siteEvent": "add_to_cart",
    "siteEventId": "XyZ-1a_bC2dEfGh3",
    "primary": false,
    "countingType": "every",
    "clickWindowDays": 30,
    "viewWindowDays": 1
  }
}

DELETE .../events/{eventId} removes the action, which on Google is an archive (state: "archived"). Google keeps it as REMOVED with its history, and PATCH with enabled: true restores it.

An action is always created enabled.

The same actions are also reachable as website tag actions.

What the API cannot do

Install on a store

POST .../tracking-tags/{tagId}/install with a storeAccountId installs the tag. What it fires depends on the conversion actions:

• Shopify: Google counts only events that have their own conversion action.
  • The store sends a conversion only for page_view, add_to_cart, initiate_checkout and purchase.
  • It sends one only when the account has an enabled WEBPAGE action of the matching category with a label. The primary-for-goal action wins, then the lowest id.
  • Product views, searches and payment info are never sent. Google has no category for search or payment info, and pointing product views at the page-view action would count every product page twice.
  • A tag with no mapped action installs but sends nothing. See the event mapping.
• WordPress: the gtag.js base code (its config call is the page view) plus the PAGE_VIEW conversion snippet when the account has one. The official fallback is Google's Site Kit by Google plugin.

Install calls read the tag first. Re-install after you add or relabel conversion actions, because the store keeps the labels it was installed with.

If it fails

Related

• Pixels and tracking tags: the cross-platform model and capability matrix.
• Conversions: server-side uploads and conversion goals.
• URL tracking tags: the campaign's tracking template and final URL suffix.
• Get tracking tag and Install on a store: every field.