Out of the box, Adobe Campaign Standard (ACS) can empower campaign teams to get proofs-of-concepts off the ground quickly with little to no code. Traditional email marketing teams usually lean toward Campaign Classic because they focus on advanced data processing. But ACS is built fundamentally differently. 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 structure 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 , open rates, and click-through rates. We have to ask ourselves, “What action do I want the user to take?” This process often sees email CTAs going to makeshift campaign-based landing pages, whether through 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 ACS Services in particular. The following architecture is for an ACS Preference Center. It allows users 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 called 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 to 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 from 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.It is also possible to access the source code from this UI, allowing frontend developers to uplift the radio button code snippet into custom HTML pages (but the page must remain hosted in ACS).
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 preference center access from the website, the ACS pKey must 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.
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 before programming the full logic.
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 adapability has been accommodated through ACS workflows that enable 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 accommodating business practitioners as they create minimum viable products. This capability is incredibly helpful for ironing out details before committing to a development plan, which is often made in support of the initial build.