Out of the box, Adobe Campaign Standard (ACS) can empower campaign teams to get proof-of-concepts off the ground quickly with little to no code. More traditional email marketing teams usually lean toward Campaign Classic because they focus on advance data processing. But ACS is built fundamentally different. It facilitates cross-channel campaign management. This capability can be seen in action with a combination of ACS’s super-sleek Services and Landing Pages, which together can close the gap between digital and data teams.
ACS Services are fixed structure data schemas with out-of-the-box API capabilities. This helps facilitate real-time data exchanges between website visitors and CRM systems.
ACS Landing Pages are webpages hosted on the ACS domain that provide campaign teams a tactical solution to promptly spin up webpages that support multichannel marketing campaigns. This enables campaign teams to be more independent, as they have more control over the UX and are less likely to stumble into blockers from digital teams.
Today’s email marketers must consider the user journey beyond email subject lines and opens and clicks and ask themselves, “What action do I want the user to take?” This often sees email CTAs going to makeshift campaign-based landing pages, whether it is a special promotion, event sign-up, or new product releases. Landing pages can also be used for more indefinite solutions such as marketing permissions.
ACS Landing Pages directly interact with ACS’s database, and in particular ACS Services. The following architecture is for an ACS Preference Center. It allows a user to manage their marketing preferences on an ACS Landing page (Preference Center), which they can access by clicking at the bottom of an email.
Let’s start with the user’s profile. Each ACS profile has a unique user identifier known as the “pKey”. When the pKey is appended as a URL parameter to the landing page, ACS can use the pKey to get user data. To unify this process, we can capitalize on ACS’s content blocks (predefined user variables) to build an on-brand HTML email module that will build a unique landing page URL for each email recipient.
Preference centers can be built using out-of-the-box ACS landing page subscription forms. As you can see form the screen grab below, radio buttons (circled in blue) can be directly linked to ACS’s services (orange circle). When a user arrives at the preference center, their current service subscription will be loaded, and upon clicking the radio button a user can opt in or out of the given service, in real time. From this UI it is also possible to access the source code, and this allows frontend developers to uplift the radio button code snippet into custom HTML pages (but the page must remain hosted in ACS).
Built-in ACS UI
User can only access preference center from an email (making it difficult to opt-in to marketing)
Outside of website ecosystem
Hosted on company's ACS domain
The ACS approach mentioned above is a great first step, and in the interest of Agile methodology, offers a lot of value quickly and without having to commit too much developer resources. But preference center access is only possible from an email, because the user pKey needs to be appended to the URL and this pKey is only in ACS. UX can be improved by allowing users to access the preference center from their website account.
To allow for preference center access from the website, the ACS pKey needs to be retrieved when a user logs in. This pKey can then be appended to a link to the preference center, enabling ACS to load the user’s preferences. The most straightforward solution would be to duplicate the ACS profile schema in whichever CRM database or CDP is referenced for website account access. This uplift in design is highlighted in green in the following architecture.
Linked to the website ecosystem
Preference center hosted on company's ACS domain
We could be cheeky and create the ACS preference center as an Iframe and host it on the website. But for a more timeless and robust solution, we would want to level up with ACS APIs.
By introducing ACS APIs, we no longer need to integrate ACS with CRM/CDP. Instead the website can interact directly with ACS data to retrieve the user’s pKey (highlighted orange below). This is achieved through an out-of-the box API call that can get profile information based on a user’s email address. A secondary benefit of this approach is that the API calls can be hosted on the core website, as the APIs can directly update ACS services.
This approach will require development work on both Adobe I/O and custom code on your website. Adobe I/O will enable integration with ACS and is where the private/public keys are set up. From here, development teams can set up their API platform. Adobe recommends Postman and provides a JSON collection of example API calls, which can be uplifted. This is a great starting point as API calls can be prepared and QA’d prior to programming the full logic.
Inside website ecosystem
No need to involve data/CRM teams
APIs can be uplifted to other systems, such as apps and list-unsubscribes
Full-stack development required
Adobe Console and API knowledge required
Adobe has also made it possible to implement a hybrid approach between API and FTP data transfers, which allows flexibility when working with third parties and legacy IT systems. This has been accommodated through ACS workflows that allow users to query the entire ACS database and then update ACS services accordingly using the “Subscription Services” process. In the example below I’m selecting all app signups, segmenting by subscription and finally updating the correct ACS service.
It’s great to see a marketing platform be so accommodating to business practitioners creating minimum viable products. This is incredibly helpful for ironing out details before committing to a development plan, which is often made to supplement the initial build.