Adobe Champion Office Hours - January 2026 — Key Takeaways

Adobe Marketo Engage User Groups | 20260116 | 58:09

This session from Adobe Marketo Engage User Groups covered a lot of ground. 4 segments stood out as worth your time. Everything below links directly to the timestamp in the original video.

Content Fragments, Brand Themes, and AEM Asset Cloning: Practical Lessons from the New Marketo Email Designer

Topic: new-features  |  Speakers: Melina Chan, Darshil Shah, Pierre Flovie

A recurring pattern among early adopters of the new Marketo email designer is that the initial learning curve is steep but the operational payoff is significant. One practitioner described an onboarding arc that mirrors the old designer's ramp-up: time spent understanding where structural elements, fragments, and CSS controls live before the tool becomes genuinely productive. After roughly three months of active use, one organization reported estimated savings of approximately $40,000 AUD attributed to reduced external template production costs.

Content fragments emerged as a standout capability. A practitioner demonstrated using fragments to compose email templates without writing code, while locking specific sections — such as headers, footers, and compliance modules — to prevent unauthorized edits. Brand themes can be applied at the fragment level, providing a guardrail for visual consistency across sends. On CSS: some knowledge is required, particularly for custom fonts and structural attributes, which are applied at the template level rather than within individual fragments.

For teams integrating AEM assets into the new designer, a specific operational risk was raised: AEM assets linked into emails can be overwritten by other users in large organizations, directly impacting live emails. The recommended mitigation is to clone any AEM asset used in an email and isolate it in a protected folder before building or testing. AB testing between old and new designer emails is supported, but this AEM asset governance issue applies with particular urgency in that context.

Key takeaways:

• Plan for a meaningful ramp-up period when adopting the new email designer — the learning curve mirrors that of the legacy designer and is not plug-and-play.
• Use content fragments to modularize email templates and lock sections (headers, footers, compliance blocks) that should not be edited by end users.
• Apply brand themes at the fragment level to enforce visual consistency without relying on individual contributors to manually maintain brand standards.
• Some CSS knowledge is necessary for initial template setup, particularly for custom fonts and structural overrides applied at the template level.
• When using AEM assets in emails, clone assets into an access-controlled folder before referencing them — shared AEM environments create a real risk of mid-campaign asset overwrite.

Why this matters: If your team is still in 'wait and see' mode on the new email designer, the operational and governance patterns shared here give you a concrete framework for de-risking the transition. The AEM asset cloning issue in particular is the kind of thing that only surfaces after something breaks in production.

🎬 Watch this segment: 32:09

A Three-Phase Framework for Consolidating Two Marketo Instances Without Losing Operational Continuity

Topic: operations  |  Speaker: Darshil Shah

Instance consolidation — merging two separate Marketo environments into one — is structurally similar to a greenfield implementation but with substantially more complexity: existing processes, established user habits, and conflicting conventions all have to be rationalized simultaneously. A practitioner who has led multiple consolidations outlined a three-phase approach: strategy, technical migration, and business process alignment, with the strategy phase carrying the most upstream risk if skipped or rushed.

Within the strategy phase, several concrete workstreams were identified. An instance inventory spreadsheet cataloguing all marketing assets — email templates, landing page templates, operational programs — is a recommended starting point for determining what moves to the destination instance. A RACI matrix helps assign ownership across what is typically a cross-functional effort. Naming convention standardization is flagged as a particularly high-stakes decision: two instances will almost certainly have divergent conventions, and the merged instance needs a single enforced standard before migration begins. Program channel taxonomy and status values also need to be defined for the destination instance. Critically, the lead management framework decisions — whether to merge or maintain separate scoring models, lifecycle stage definitions, and qualified lead handoff processes — must be resolved at the strategy level, not retrofitted after migration. CRM sync complexity is compounded significantly if the two instances are connected to different CRM systems.

The technical migration phase involves asset portability decisions (API-based migration versus direct instance bridging) and dependency mapping. The third phase, business process alignment, is primarily a change management challenge: end users, including sales, need to be brought along to the new naming conventions and workflows, not just notified after the fact.

Key takeaways:

• Build an instance inventory spreadsheet before any migration work begins — knowing what exists in both instances is a prerequisite to deciding what moves.
• Resolve naming convention standardization and program channel taxonomy in the strategy phase; retrofitting these after migration creates ongoing operational debt.
• Lead management framework decisions (scoring models, lifecycle stages, MQL handoff processes) must be aligned between merging business units before technical migration starts.
• CRM sync architecture is a significant complexity multiplier — consolidations involving two instances connected to different CRMs require dedicated planning for object handling.
• Business process alignment and change management with sales and marketing end users is a distinct phase, not an afterthought — without it, the consolidated instance will be used inconsistently.

Why this matters: If your organization is facing a merger, acquisition, or business unit consolidation that involves two Marketo instances, this framework gives you a sequenced checklist to work from before a single asset is moved. The strategy phase decisions — particularly around lead management and naming conventions — are where most consolidations accumulate the most technical debt.

🎬 Watch this segment: 13:54

Dynamic Chat Knowledge Library Configuration, IP Whitelisting, and Predictive Scoring Feedback Loops: Non-Obvious AI Operational Details

Topic: new-features  |  Speakers: Darshil Shah, Laura Dingler

Two operationally non-obvious requirements for Dynamic Chat's generative AI surfaced in this segment. First, knowledge sources used to train the chat engine must be publicly accessible — pages behind login walls cannot be crawled and will silently produce gaps in the chatbot's knowledge base. Second, Dynamic Chat uses region-specific IP addresses to crawl web pages, and those IPs must be explicitly whitelisted in relevant security configurations for crawling to succeed. Both issues are easy to miss during initial setup and can result in a chatbot that appears functional but is drawing on incomplete information.

A practitioner also highlighted the unanswered questions log as an underused operational lever. Dynamic Chat surfaces questions it could not answer for admin review — treating this as a regular review queue and manually providing answers, tagged to relevant knowledge base assets, progressively improves response quality over time. On the question of whether Dynamic Chat can tailor answers based on a user's prior selections within a session, the assessment was that context-dependent variation in responses is possible when prior conversation context is included in the query, but the behavior is nuanced and warrants further testing specific to each deployment's question patterns.

For predictive lead scoring, one team described deploying a custom AI-powered scoring model that incorporates a feedback loop: conversion data and engagement history are used to dynamically adjust the scoring threshold required for a lead to advance lifecycle stages. This represents a more sophisticated pattern than static demographic or behavioral scoring, with the model recalibrating based on observed outcomes rather than fixed rules.

Key takeaways:

• Dynamic Chat cannot crawl pages behind authentication — ensure all knowledge source URLs are publicly accessible before configuring the knowledge library.
• Whitelist the region-specific Marketo Dynamic Chat crawler IPs in your web security configuration; without this, web page crawling will fail silently.
• Treat the unanswered questions log in Dynamic Chat as an ongoing maintenance queue — reviewing and answering missed questions, tagged to relevant knowledge assets, directly improves chatbot response coverage over time.
• Predictive lead scoring feedback loops — where conversion data dynamically adjusts scoring thresholds — offer a more adaptive alternative to static scoring models and are worth evaluating for mature instances with sufficient historical data.
• Context-dependent response variation in Dynamic Chat is possible when prior conversation context is included in the query, but behavior should be validated empirically for each specific deployment.

Why this matters: If your team has deployed or is planning to deploy Dynamic Chat's AI features, the IP whitelisting requirement and the unanswered questions review loop are two operational details that are easy to miss but material to how well the tool actually performs. The predictive scoring feedback loop pattern is also worth a closer look if your current scoring model relies entirely on static rules.

🎬 Watch this segment: 42:05

Keeping Nurture Complexity in the Gating Layer, Not the Program Count: Lessons from Multi-Touch Demand Programs

Topic: campaign-architecture  |  Speaker: Melina Chan

A practitioner made a pointed structural argument about nurture program architecture: complexity belongs at the gating and content layer — who enters, who exits, how leads progress or regress based on lifecycle stage — not in the number of programs. As an illustration, one team reduced a nurture program from over 300 emails to 15 by applying Velocity scripting to handle personalization and conditional logic within a smaller set of assets. The implication is that practitioners who manage sprawling program structures are often solving a content variation problem with architecture when the solution should be at the template and scripting layer.

On the question of drip versus behavioral nurture, a clear distinction was drawn: drip nurture is time-based and sequence-driven (send email every N days for X weeks), while a true nurture program introduces dynamic content, engagement-based branching, and behavioral signals to determine what a lead receives next. This distinction matters for program design and for setting stakeholder expectations about what the program can and cannot respond to.

Two quick-win nurture patterns were shared. An abandoned-form or abandoned-registration flow — using push notification or messaging channels to re-engage users who did not complete a journey — was cited as a reliable pilot candidate for testing multi-touch attribution. A re-engagement program targeting previously active leads who had gone dormant over several months was also described: streams were structured by lifecycle stage, populated with high-performing content not previously sent to those leads, and resulted in approximately 50–60 opportunities created within a month. A CRO-focused example was also noted — adjusting call-to-action copy and button placement on a landing page generated a notable spike in conversions within two weeks.

Key takeaways:

• Locate nurture complexity in the gating and content logic layer — who enters, exits, progresses, or regresses — rather than multiplying programs; Velocity scripting can dramatically reduce email volume while maintaining personalization.
• Distinguish drip nurture (time-based sequencing) from behavioral nurture (dynamic content and engagement-driven branching) before designing programs — they require different architectures and set different stakeholder expectations.
• Abandoned-journey flows (form, registration, or checkout) targeting users who did not complete a step are a reliable pilot candidate for testing multi-touch engagement with minimal build complexity.
• Re-engagement programs for dormant leads should be segmented by lifecycle stage and populated with content that has not been previously sent to those individuals to maximize the probability of re-sparking interest.
• CRO improvements to landing pages — particularly call-to-action copy and button prominence — can produce measurable conversion lifts and are often overlooked as part of a nurture optimization pass.

Why this matters: If your nurture programs have grown into sprawling multi-program structures that are difficult to audit or update, the architectural argument here is worth pressure-testing against your own setup. The 300-to-15 email reduction via Velocity scripting is a concrete proof point that program proliferation is not the only way to handle content variation.

🎬 Watch this segment: 20:22

Content summarized from publicly available MUG recordings. Not affiliated with Adobe. Summaries reflect my interpretation — always validate before implementing in your environment.

This is a personal project by JP Garcia. I work at Kapturall but this publication is independent and not affiliated with or endorsed by my employer. All credit belongs to the original speakers and Adobe Marketo Engage User Groups. I curate and link back to source — I never re-upload or reproduce full sessions. Full disclaimer →

🤔 Why have these segments been selected?