{"id":79,"date":"2026-07-11T18:14:10","date_gmt":"2026-07-11T16:14:10","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=79"},"modified":"2026-10-24T00:39:06","modified_gmt":"2026-10-23T22:39:06","slug":"vertex-ai-in-e-commerce-recommendation-engine-gtm-integration-and-data","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-marketing\/vertex-ai-in-e-commerce-recommendation-engine-gtm-integration-and-data\/","title":{"rendered":"Vertex AI in E-Commerce: Recommendation Engine, GTM Integration and Data Readiness Tiers"},"content":{"rendered":"

A recommendation engine selects products for a particular context, such as a product page or shopping cart. Google Cloud offers managed commerce recommendations alongside search. The current documentation calls the product AI Commerce Search in Gemini Enterprise for Customer Experience<\/strong>; the Retail API remains relevant to integration. Vertex AI is a broader platform, not the name of one universal recommendation model.<\/p>\n

What recommendations can improve<\/h2>\n

Relevant suggestions can help product discovery. Higher conversion rates or average order values are possible outcomes, not guaranteed effects. A controlled A\/B test should compare the new recommendations with the existing storefront using a predefined business metric. Latency, unavailable items and poor catalog data can offset any improvement.<\/p>\n

Three separate data paths<\/h2>\n
    \n
  1. Catalog:<\/strong> product IDs, names, prices and availability reach the commerce service through an import or update pipeline.<\/li>\n
  2. Events:<\/strong> product views, cart changes and completed purchases provide behavioral signals. IDs in events must match the catalog.<\/li>\n
  3. Recommendations:<\/strong> the application requests results and displays the selected products. Sending events alone does not render a recommendation panel.<\/li>\n<\/ol>\n

    Client-side and server-side GTM<\/h2>\n

    A web container runs in the browser. A server container receives requests and can validate, transform and forward event data. If the initial browser request is blocked or never sent, server-side GTM cannot reconstruct that interaction. Backend purchase events provide another input, but also require reliable delivery and duplicate handling.<\/p>\n

    Moving some processing to a server can reduce browser work; the actual performance effect needs measurement. Server infrastructure also introduces operation, latency and cost. Private service-account credentials belong on the server. Restricted API keys used by documented browser collection methods are a different credential type; a visible key is not automatically a leaked private service-account secret.<\/p>\n

    Data readiness: search tiers are not recommendation tiers<\/h2>\n

    Google documents performance tiers for text and browse search. Recommendation models instead have model-specific event types, volumes and collection windows. There is no universal three-tier ladder that unlocks every recommendation model after 90 days.<\/p>\n

    For example, Similar Items<\/em> can work from catalog data without user events. Frequently Bought Together<\/em> needs purchase data. The current model-creation documentation and the project console determine the applicable minimums. A 90-day observation window is not necessarily a requirement to collect 90 consecutive days.<\/p>\n

    Code example: the first step only<\/h2>\n

    The following GA4-style dataLayer<\/code> event describes a product view. The push places data in the page\u2019s data layer; it does not by itself send an API request.<\/p>\n

    \/\/ Pushing Product Information to the Data Layer (Client-Side)\nwindow.dataLayer = window.dataLayer || [];\nwindow.dataLayer.push({\n  event: \"view_item\",\n  ecommerce: {\n    currency: \"USD\",\n    value: 49.99,\n    items: [\n      {\n        item_id: \"SKU_98765\",\n        item_name: \"Running Shoes XYZ\",\n        item_category: \"Footwear\",\n        price: 49.99,\n        quantity: 1\n      }\n    ]\n  }\n});<\/code><\/pre>\n
    A complete integration needs a web-container trigger and tag, transport to the intended endpoint, and a receiving integration. In a custom Retail API mapping, view_item<\/code> maps to detail-page-view<\/code>, and the item ID must identify the catalog product. Required visitor information and the API-specific event structure must also be supplied. The original GA4 object is not a ready-to-send Retail API payload.<\/p>\n
    Checks before release<\/h2>\n
    A useful acceptance test follows one known product from catalog import through a recorded event to a displayed recommendation. Monitoring should check rejected events, missing product joins, delayed updates, duplicate purchases and empty results. Comparing catalog counts alone misses changed prices and swapped IDs. Data collection also needs the applicable privacy controls; changing the transport does not remove those requirements.<\/p>\n
    \n\"Configured
    Configured event transport through GTM and the Retail API; search tiers and recommendation-model requirements are separate.<\/figcaption><\/figure>\n
    \n
    Questions and answers<\/h2>\n
    Does a tracking outage reset a 90-day counter?<\/h3>\n
    No universal counter exists for these recommendation models. A gap reduces the available data within the relevant collection window. Model status and data-quality diagnostics show whether the remaining data meets the chosen model\u2019s requirements.<\/p>\n
    How do recommendations reach the storefront?<\/h3>\n
    The application can render results on the server or expose a controlled endpoint for the page. Authentication, input validation and access limits remain necessary. Personalized results must not be reused for a different visitor.<\/p>\n
    Does a catalog import keep prices current forever?<\/h3>\n
    No. Product changes require subsequent updates. Freshness checks should compare prices, availability and product IDs with the shop, not just count records.<\/p>\n<\/div>\n
    \n
    Sources<\/h2>\n