Ready to Use Recipes: 28 Prebuilt GTM Setups You Inject

2026-08-24

A tour of the Ready to Use Recipes library in AI Tag Manager: what each recipe contains, how direct injection into a GTM workspace works, and when a recipe beats the AI generator.

Most GTM work is not novel. Someone asks for scroll depth, outbound link clicks, YouTube or Vimeo engagement, a Calendly booking event, a Contact Form 7 submission. You have built each of these before, and each time you rebuild the same custom HTML listener, the same custom event trigger, the same dataLayer variables and the same GA4 event tag from memory or a half-remembered blog post. The setup is not hard. It is slow, and easy to get subtly wrong while handling three other containers.

Ready to Use Recipes in AI Tag Manager is a library of these standard setups, stored as complete GTM container JSON and injected into a workspace you choose. There are 28 verified recipes at the moment. You pick one, confirm the target, click one button, and the tags, triggers and variables land in your workspace as unpublished changes. This post covers what a recipe contains, how injection works, what the tool does not do, and when the AI generator is the better choice.

What a recipe is, in GTM terms

A recipe is a row in the recipe library with a name, a description, an industry category, a recipe type, a quality score and one field that matters more than the rest: gtm_container_json. That field holds a standard GTM container export, the same shape you get from Admin, Export Container in GTM: a containerVersion object with three arrays, tag, trigger and variable.

The page reads those arrays to show the counts on each card. Nothing is generated at click time. What you inject is exactly what is stored, which is the point: a recipe is deterministic and has been checked by a person before it was marked verified. The page only loads rows with a verified status, sorted by quality score, so anything uploaded but not yet approved never appears.

Here is what the Vimeo recipe contains, pulled from the stored JSON. It is typical of the media tracking group.

Tags
  cHTML - vimeo listener                        (html)
  GA4 event - vimeo video - start complete      (gaawe)
  GA4 event - vimeo video - progress            (gaawe)

Triggers
  Window Loaded - vimeo player is on a page     (WINDOW_LOADED)
  custom - vimeo_video - start complete         (CUSTOM_EVENT)
  custom - vimeo_video - progress               (CUSTOM_EVENT)

Variables
  dlv - video_title        (Data Layer Variable)
  dlv - video_url          (Data Layer Variable)
  dlv - video_percent      (Data Layer Variable)
  dlv - video_status       (Data Layer Variable)
  cjs - is vimeo player on a page   (Custom JavaScript)

A custom HTML tag attaches a listener to the Vimeo player API and pushes vimeo_video events to the dataLayer. A custom JavaScript variable checks whether a Vimeo iframe exists so the listener only fires where needed. Two custom event triggers pick up the pushes, and two GA4 event tags send them on with values read from dataLayer variables. The recipes also follow a prefix style (dlv -, cjs -, cHTML -, GA4 event -) close to the one in the post on naming conventions for large GTM containers, which makes them easy to spot in a later audit.

The 28 verified recipes in the library today

Every recipe currently marked verified, with the counts shown on its card. The library is data, not code, so this is a snapshot from late August 2026.

The two utility recipes with 13 variables and no triggers (AJAX Tracking and UTMZ Cookie Replicator) are infrastructure: a listener or cookie writer plus the variables to read from it, with your own tags built on top.

How to use it, step by step

The route is /gtm-json-generator. It needs a signed-in account with GTM access granted through Google.

1. Pick the target. The container picker at the top carries the hint "Pick the account, container and workspace a recipe or template will be injected into." The workspace is not optional. If you click Use Recipe without one, the page shows "Connect your GTM container first" and stops.
2. Find the recipe. The segmented control shows "Recipes" and "Templates" with a count on each. Use the "Search recipes..." box (it matches name and description) and the "All Industries" dropdown. There is also a grid/list toggle; grid for browsing, list when you know the name.
3. Open it. Each card shows the industry badge, the name, a short description and the tag, trigger and variable counts. Click Use Recipe.
4. Confirm. A dialog titled "Inject Recipe" repeats the name and description and shows "Container:" followed by the one you picked. There is one button: Inject to GTM. While it runs the label reads "Injecting to GTM...".
5. Read the result. On success the dialog shows "Injection Successful" with the counts created and a link to the workspace. On failure it shows "Injection Failed" with the backend's error text.

There is no configuration form in the dialog. The recipe is injected as stored, and any adjustment (a different trigger condition, a renamed event, a specific measurement ID) is made in the GTM workspace afterwards, where you have the full editor anyway.

What the configure step actually is

A recipe does not ask questions before it injects. The variables it needs are dataLayer variables or built-in click variables, which need no per-site input. The one value that varies by site is the GA4 measurement ID, and the injection function handles that on purpose.

When the backend copies a GA4 event tag into your workspace, it looks for a measurementId or measurementIdOverride parameter. If the stored value is empty or the placeholder G-XXXXXXXXXX, the parameter is dropped, so the tag falls back to the Google tag already in your container. A real ID is kept as an override. In practice a recipe's GA4 event tags attach to your existing GA4 setup untouched, as long as the container already has a Google tag.

So the configure step is: pick the workspace, inject, open the workspace and review. The review is short because the recipe is small. Check the trigger conditions suit your site (the outbound link recipe compares against Click Hostname, which is wrong for sites that link between subdomains you consider internal), rename anything that clashes with your conventions, and preview.

Direct inject: what happens in the workspace

Direct inject calls the gtm-direct-inject edge function with your account ID, container ID, workspace ID and the recipe JSON. The function uses the GTM API with the Google token you granted at sign-in. It creates elements inside the workspace you named, and only there. It does not create a version and it does not publish.

The order of operations matters when the container already has some of the pieces. The function lists the triggers and variables already in the workspace, creates the recipe's variables (skipping any whose name exists), then its triggers (same rule), then its tags, remapping trigger references to whichever trigger ID ended up in the workspace. The response includes a skipped count, so if you inject Scroll Tracking into a container that already has a trigger called "Scroll", you get the tag and the trigger is reused rather than duplicated.

Recipe injection skips the schema validation pass the general injector runs; recipes are already in GTM export format and verified, so there is nothing to auto-fix.

Export as JSON versus inject

The Recipes tab has no download button. A recipe is stored as a container export, but the page's only action is Inject to GTM. If you want the recipe as a file, inject it into a scratch workspace or an empty container, then use GTM's own Admin, Export Container, which gives you the standard JSON with your container's IDs filled in. That file can be imported with Merge into any other container, including ones your AI Tag Manager account cannot reach.

• Inject is a live write into a workspace through the GTM API. It is fast, de-duplicates by name, and leaves the changes unpublished so you can preview first. It needs a connected container.
• Export and import is the classic route. It works for containers you lack API access to, lets you diff the JSON in version control, and is the right answer when a client insists no third party writes to their container. The merge and conflict handling is on you.

For an agency, inject is the daily path and export the occasional one. The post on agency workspace workflows in GTM covers keeping injected changes in a named workspace per client so review and publish stay controlled.

The Templates tab, briefly

The second tab lists custom templates from a separate table. A template is also a container export, but its dialog opens a table with columns "Tag Name", "Event Name", "Trigger (Linked)" and "Variables / Parameters", a checkbox per row and a "Select All Tags" control. You choose which tags to inject, the page works out which triggers they reference, and it sends those tags, those triggers and all the template's variables. The button reads "Inject N Tags to [container name]". Templates also get a "Platform" filter that recipes do not have. A recipe is all-or-nothing because each one is a single working unit.

When a recipe beats the AI generator

AI Tag Manager also has an AI generator that builds GTM tags from a plain-English prompt. It is the right tool for anything site-specific: a purchase event with your particular dataLayer keys, GA4 events for a booking funnel no library will match, a server-side layout. The post on generating GTM tags from a description shows what that looks like.

A recipe wins in three situations.

1. The request is a named integration. "Track Calendly bookings" or "add Wistia events" has one correct answer, and the recipe already has the listener code and the event names the vendor's API emits. A model can write this code, but it writes it slightly differently each time and you test it each time. The recipe was tested once and stays the same.
2. You need to repeat it across containers. Injecting the same recipe into ten client containers gives ten identical setups with identical names, which makes any automated container audit across accounts far easier to read.
3. Speed matters more than fit. A recipe injects in seconds. If the client asked for scroll depth and you have five other things to do, inject it, preview it, move on.

The generator wins when the recipe would need more than cosmetic changes to fit. If you are planning to rewrite the listener and rename the events, describe what you want to the generator instead.

Limits and honest caveats

• No per-recipe configuration. There are no inputs before injection. Everything site-specific is done in GTM afterwards.
• No download from this page. Recipes are inject-only. Use GTM's export after injecting if you need a file.
• Nothing is published. The injection stops at the workspace. You still preview, create a version and publish. This surprises people who expect events in GA4 straight away.
• Existing names are reused, not updated. If your workspace already has a variable called dlv - video_title that reads a different key, the recipe skips creating its own and the injected tags use yours. Check the skipped count.
• Quality scores order the list. They are modest across the board (the highest today is 0.70) and are not a guarantee that a listener works on every player version.
• Custom HTML has consent implications. Several recipes rely on custom HTML listeners. Under Consent Mode v2 those tags need the same consent settings as the rest; the Consent Mode v2 playbook covers applying that after injection.
• It does not verify that events reach GA4. After publishing, run the tag verification tool against the page to confirm the recipe's events fire.

What to do next

If you have a container with a standard integration missing, open Ready to Use Recipes, pick the workspace, and inject the recipe. Preview and publish from GTM. For anything the library does not cover, take the request to the AI generator and describe it in a sentence or two. Either way, the piece you should stop doing by hand is the repeated rebuild of listeners that already exist and already work.