{"id":2496,"date":"2026-04-04T16:38:31","date_gmt":"2026-04-04T21:38:31","guid":{"rendered":"https:\/\/www.miaprova.com\/blog\/?p=2496"},"modified":"2026-04-04T17:56:06","modified_gmt":"2026-04-04T22:56:06","slug":"warehouse-to-target-using-hightouch-to-power-smarter-adobe-target-personalization-offline-profiles-real-time","status":"publish","type":"post","link":"https:\/\/www.miaprova.com\/blog\/warehouse-to-target-using-hightouch-to-power-smarter-adobe-target-personalization-offline-profiles-real-time\/","title":{"rendered":"Warehouse-to-Target: using Hightouch to power smarter Adobe Target personalization (offline profiles + real-time)"},"content":{"rendered":"\n

If you\u2019ve spent any time in Adobe Target, you\u2019ve probably hit the same ceiling I have: you can build great experiences with on-site behavior, a few profile attributes, and some Analytics segments\u2026 but your best<\/em> customer context usually lives somewhere else.<\/p>\n\n\n\n

For a lot of orgs, that \u201csomewhere else\u201d is the data warehouse (BigQuery, Snowflake, Databricks). That\u2019s where you\u2019ve got LTV, lifecycle stage, churn risk, product affinities, lead\/account health, eligibility rules, and all the modeled attributes your teams actually trust.<\/p>\n\n\n\n

This post walks through two practical ways a Hightouch user can bring warehouse attributes into Adobe Target so you can target audiences<\/strong> and personalize experiences<\/strong> with the same governed warehouse logic your business already runs on:<\/p>\n\n\n\n

    \n
  1. Offline profile syncing<\/strong> into Target\u2019s profile store (great for stable attributes & audience flags)<\/li>\n\n\n\n
  2. Real-time enrichment<\/strong> using Hightouch Personalization API<\/strong> (great for fast-changing \/ computed-at-request-time attributes)<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    The core Target concept you need to get right: identity<\/h2>\n\n\n\n

    Before we talk about pipelines, you need a clean plan for who<\/em> you\u2019re updating.<\/p>\n\n\n\n

    Adobe Target\u2019s mbox3rdPartyId<\/code> is essentially \u201cyour ID for this person\u201d (loyalty ID, customer ID, membership ID, etc.). When you pass it, Target links it to Target\u2019s own anonymous ID (PCID) and merges profiles, with the 3rd-party ID taking precedence in merge conflicts.<\/p>\n\n\n\n

    In practice, that means:<\/p>\n\n\n\n

      \n
    • If you can identify a visitor (login, known ID, authenticated session), use a stable 3rd-party ID<\/strong>.<\/li>\n\n\n\n
    • Decide whether you will use mbox3rdPartyId<\/code> \/ thirdPartyId<\/code> or<\/em> ECID customerIds<\/code> patterns\u2014Adobe warns against mixing them for the same visitor because it can create bad merges.<\/li>\n<\/ul>\n\n\n\n

      Once identity is stable, everything else gets much easier.<\/p>\n\n\n\n

      \n\n\n\n
      \"\"<\/figure>\n\n\n\n

      Path 1: Offline profile syncing (warehouse \u2192 Target profile store)<\/h2>\n\n\n\n

      This is the \u201creverse ETL\u201d pattern. You compute attributes\/flags in the warehouse, and push them into Target so Target can use them like native profile attributes.<\/p>\n\n\n\n

      Hightouch supports syncing Profiles<\/strong> into Adobe Target (create\/update visitor profile attributes), and does it via Target\u2019s Bulk Profile API<\/strong>.<\/p>\n\n\n\n

      When offline syncing is the best fit<\/h3>\n\n\n\n

      Use this when:<\/p>\n\n\n\n

        \n
      • Attributes change daily\/hourly<\/strong> (or even every few minutes), but not \u201cper pageview\u201d<\/li>\n\n\n\n
      • You want targeting based on modeled business logic<\/strong> (eligibility, lifecycle, LTV buckets)<\/li>\n\n\n\n
      • You want zero added latency<\/strong> on the Target request (because Target already has the data)<\/li>\n<\/ul>\n\n\n\n

        What you typically sync<\/h3>\n\n\n\n

        Think \u201cdurable decisioning inputs,\u201d like:<\/p>\n\n\n\n

          \n
        • loyalty_tier<\/code>: Bronze \/ Silver \/ Gold<\/li>\n\n\n\n
        • ltv_12m_bucket<\/code>: low \/ mid \/ high<\/li>\n\n\n\n
        • churn_risk<\/code>: low \/ medium \/ high<\/li>\n\n\n\n
        • eligible_for_offer_X<\/code>: true\/false<\/li>\n\n\n\n
        • preferred_category<\/code>: \u201cclosets\u201d, \u201ckitchen\u201d, \u201ctravel\u201d, etc.<\/li>\n<\/ul>\n\n\n\n

          Step-by-step (practitioner version)<\/h3>\n\n\n\n

          1) Build a model in the warehouse<\/h4>\n\n\n\n

          Example (conceptual) output columns:<\/p>\n\n\n\n

            \n
          • customer_id<\/code> (the ID you\u2019ll match on in Target)<\/li>\n\n\n\n
          • loyalty_tier<\/code><\/li>\n\n\n\n
          • ltv_12m<\/code><\/li>\n\n\n\n
          • next_best_category<\/code><\/li>\n\n\n\n
          • offer_eligibility_flag<\/code><\/li>\n<\/ul>\n\n\n\n

            In Hightouch terms, this is your model<\/strong> (a SQL-defined dataset).<\/p>\n\n\n\n

            2) Configure the Adobe Target destination in Hightouch<\/h4>\n\n\n\n

            A few key details from Hightouch\u2019s Target destination docs:<\/p>\n\n\n\n

              \n
            • Adobe Target is a premium destination<\/strong> (Business tier plans).<\/li>\n\n\n\n
            • You\u2019ll authenticate using Adobe Developer Console OAuth Server-to-Server, and you must enable \u201cRequire Authentication\u201d for the Target Profile API in Target admin settings.<\/li>\n<\/ul>\n\n\n\n

              3) Choose record matching (this matters)<\/h4>\n\n\n\n

              Hightouch lets you match warehouse rows to Target profiles using:<\/p>\n\n\n\n

                \n
              • thirdPartyId<\/code> (recommended<\/strong>)<\/li>\n\n\n\n
              • pcID<\/code><\/li>\n<\/ul>\n\n\n\n

                In almost every real-world Target implementation I\u2019ve seen, thirdPartyId<\/code> is the cleanest long-term approach\u2014because you control it and it\u2019s stable across devices once associated.<\/p>\n\n\n\n

                4) Map fields to Target profile attributes<\/h4>\n\n\n\n

                Map your model columns to Target fields, keeping types consistent.<\/p>\n\n\n\n

                My strong recommendation: don\u2019t send raw continuous values unless you truly need them<\/strong>. Instead, bucketize in the warehouse (e.g., ltv_bucket<\/code>) so Target targeting rules stay simple and stable.<\/p>\n\n\n\n

                5) (Optional but powerful) Sync \u201caudience flags\u201d<\/h4>\n\n\n\n

                Hightouch can create a very simple \u201cmembership\u201d attribute pattern for you:<\/p>\n\n\n\n

                It sets a boolean attribute like __hightouch_audience_{model name}<\/code> and then builds an audience that includes profiles where that flag is true<\/code>.<\/p>\n\n\n\n

                This is a cheat code for Target teams:<\/p>\n\n\n\n

                  \n
                • Warehouse decides membership<\/li>\n\n\n\n
                • Target just consumes it cleanly<\/li>\n\n\n\n
                • No one is rewriting complex segmentation logic in the UI<\/li>\n<\/ul>\n\n\n\n

                  6) Use the attributes in Target<\/h4>\n\n\n\n

                  Now your Target practitioners can:<\/p>\n\n\n\n

                    \n
                  • Create audiences based on profile attributes<\/li>\n\n\n\n
                  • Target experiences\/offers accordingly<\/li>\n\n\n\n
                  • Use attributes in personalization logic (e.g., Experience A for Gold tier)<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n

                    Path 2: Real-time enrichment using Hightouch Personalization API (warehouse \u2192 low-latency API \u2192 Target decisioning)<\/h2>\n\n\n\n

                    Offline syncing is great, but sometimes you need freshness<\/em> or runtime computation<\/em>:<\/p>\n\n\n\n

                      \n
                    • \u201cWhat products are in stock near this user right now?\u201d<\/li>\n\n\n\n
                    • \u201cWhat\u2019s the user\u2019s most recent predicted propensity after last night\u2019s model run?\u201d<\/li>\n\n\n\n
                    • \u201cWhat\u2019s the next-best-offer computed from their last 5 actions?\u201d<\/li>\n<\/ul>\n\n\n\n

                      That\u2019s where Hightouch Personalization API<\/strong> fits.<\/p>\n\n\n\n

                      Hightouch describes it as a managed, low-latency API that acts like a cache for your warehouse-defined models.<\/p>\n\n\n\n

                      The key security rule<\/h3>\n\n\n\n

                      Hightouch explicitly recommends not<\/strong> calling the Personalization API directly from untrusted clients (like a browser). Instead, proxy through a service you control.<\/p>\n\n\n\n

                      That lines up perfectly with how many Target teams already think about \u201cdecision services.\u201d<\/p>\n\n\n\n

                      A practical architecture for Target<\/h3>\n\n\n\n

                      Warehouse \u2192 Hightouch Personalization API \u2192 Your backend\/edge \u2192 Target<\/strong><\/p>\n\n\n\n

                        \n
                      1. You define a \u201ccustomers\u201d collection keyed by customer_id<\/code> (or another stable key).<\/li>\n\n\n\n
                      2. Hightouch materializes it into a low-latency cache and exposes HTTP endpoints.<\/li>\n\n\n\n
                      3. At request time, your backend<\/strong> fetches the record and then:\n
                          \n
                        • passes relevant values into Target as mbox parameters<\/strong>, or<\/li>\n\n\n\n
                        • uses Target server-side decisioning (Delivery API), or<\/li>\n\n\n\n
                        • feeds Target via a Data Provider endpoint you control (more on that next)<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                          Two ways to wire \u201creal-time data\u201d into Target<\/h3>\n\n\n\n

                          Option A: Your app backend calls Hightouch, then calls Target (server-side decisioning)<\/h4>\n\n\n\n

                          This is my favorite when you already have server-side rendering, an API gateway, or edge functions.<\/p>\n\n\n\n

                          Flow:<\/p>\n\n\n\n

                            \n
                          • request comes in<\/li>\n\n\n\n
                          • you look up user context in Personalization API<\/li>\n\n\n\n
                          • you call Target\u2019s Delivery API with thirdPartyId<\/code> plus the enrichment parameters<\/li>\n\n\n\n
                          • you render the experience<\/li>\n<\/ul>\n\n\n\n

                            Why it\u2019s nice:<\/p>\n\n\n\n

                              \n
                            • clean latency budget control<\/li>\n\n\n\n
                            • easy to log\/debug<\/li>\n\n\n\n
                            • no sensitive keys exposed client-side<\/li>\n<\/ul>\n\n\n\n

                              Option B: Target calls you<\/em> (Data Provider), and you call Hightouch behind the scenes<\/h4>\n\n\n\n

                              If you\u2019re using Target\u2019s Data Provider feature, you can implement the provider endpoint to:<\/p>\n\n\n\n

                                \n
                              • accept Target\u2019s identifiers<\/li>\n\n\n\n
                              • call Hightouch Personalization API<\/li>\n\n\n\n
                              • return a lightweight JSON payload for Target to use in the activity<\/li>\n<\/ul>\n\n\n\n

                                Why it\u2019s nice:<\/p>\n\n\n\n

                                  \n
                                • keeps page\/app code simpler<\/li>\n\n\n\n
                                • standardizes enrichment across activities<\/li>\n<\/ul>\n\n\n\n

                                  Tradeoff:<\/p>\n\n\n\n

                                    \n
                                  • you\u2019re adding a dependency into the Target decision path, so your endpoint must be very reliable and fast.<\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n

                                    Offline vs real-time: how I decide as a Target practitioner<\/h2>\n\n\n\n

                                    Default to offline sync<\/strong> when:<\/p>\n\n\n\n

                                      \n
                                    • the attribute is stable enough to refresh on a schedule<\/li>\n\n\n\n
                                    • you want the simplest, fastest Target execution<\/li>\n\n\n\n
                                    • the targeting logic should be governed centrally in the warehouse<\/li>\n<\/ul>\n\n\n\n

                                      Use real-time enrichment<\/strong> when:<\/p>\n\n\n\n

                                        \n
                                      • the attribute changes frequently or needs runtime computation<\/li>\n\n\n\n
                                      • you need \u201clatest known state\u201d at the moment of decision<\/li>\n\n\n\n
                                      • you\u2019re doing recommendations, inventory-aware messaging, dynamic pricing, etc.<\/li>\n<\/ul>\n\n\n\n

                                        A common hybrid that works well:<\/p>\n\n\n\n

                                          \n
                                        • Offline sync: tiers, buckets, eligibility flags, suppressions<\/li>\n\n\n\n
                                        • Real-time: \u201ctop 3 recs,\u201d nearest store, in-stock decisions, session-aware context<\/li>\n<\/ul>\n\n\n\n
                                          \n\n\n\n

                                          A concrete use case example (what this looks like in the real world)<\/h2>\n\n\n\n

                                          Let\u2019s say your warehouse defines:<\/p>\n\n\n\n

                                            \n
                                          • eligible_free_shipping = true<\/code><\/li>\n\n\n\n
                                          • loyalty_tier = \"Gold\"<\/code><\/li>\n\n\n\n
                                          • category_affinity = \"Closet Organization\"<\/code><\/li>\n\n\n\n
                                          • recommendations = [SKU123, SKU456, SKU789]<\/code><\/li>\n<\/ul>\n\n\n\n

                                            You might implement:<\/p>\n\n\n\n

                                              \n
                                            • Offline sync<\/strong> of eligible_free_shipping<\/code>, loyalty_tier<\/code>, category_affinity<\/code> (fast audience targeting inside Target)<\/li>\n\n\n\n
                                            • Real-time<\/strong> pull of recommendations<\/code> (because the list is larger, changes more often, and you don\u2019t want to jam it into profile attributes)<\/li>\n<\/ul>\n\n\n\n

                                              Then Target can:<\/p>\n\n\n\n

                                                \n
                                              • Target an activity to eligible_free_shipping == true<\/code><\/li>\n\n\n\n
                                              • Personalize hero copy based on category_affinity<\/code><\/li>\n\n\n\n
                                              • Populate a \u201cRecommended for you\u201d module with the real-time SKU list<\/li>\n<\/ul>\n\n\n\n
                                                \n\n\n\n

                                                Implementation checklist (the stuff that prevents headaches)<\/h2>\n\n\n\n
                                                  \n
                                                • Identity<\/strong>\n
                                                    \n
                                                  • Pick your \u201cknown user\u201d key (usually thirdPartyId<\/code>) and implement it consistently<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                  • Data modeling<\/strong>\n
                                                      \n
                                                    • Prefer buckets + booleans<\/strong> over raw continuous values<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                    • Sync hygiene<\/strong>\n
                                                        \n
                                                      • Ensure IDs are unique to avoid mis-updates<\/li>\n\n\n\n
                                                      • Decide delete behavior: do nothing vs clear fields managed by Hightouch<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                      • Real-time safety<\/strong>\n
                                                          \n
                                                        • Don\u2019t call Personalization API from the browser; proxy it<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                        • Activation simplicity<\/strong>\n
                                                            \n
                                                          • Consider syncing \u201caudience flags\u201d to keep Target UI rules dead simple<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                                            \n\n\n\n

                                                            Where this gets really fun (Target team payoff)<\/h2>\n\n\n\n

                                                            Once Target can \u201csee\u201d warehouse attributes, you stop building fragile, one-off targeting logic and start operating like a modern decisioning system:<\/p>\n\n\n\n

                                                              \n
                                                            • Personalize by lifecycle stage (acquisition \u2192 onboarding \u2192 retention)<\/li>\n\n\n\n
                                                            • Suppress promos for high-LTV users who don\u2019t need them<\/li>\n\n\n\n
                                                            • Show different experiences by account health (B2B)<\/li>\n\n\n\n
                                                            • Trigger messaging based on modeled propensities<\/li>\n\n\n\n
                                                            • Keep your personalization consistent across Target, email, paid media, and in-app<\/li>\n<\/ul>\n\n\n\n

                                                              And most importantly: your Target activities stop being disconnected experiments and start becoming the activation layer for your warehouse truth<\/strong>.<\/p>\n\n\n\n

                                                              \n