Background
A large number of Oracle and 3rd party CX applications include segmentation as a key part of their feature set. Trouble is, most of these implementations are siloed and proprietary. Further very few of these segment-aware applications expose services to the underlying segment mechanism, making integrations — with regard to segments — difficult if not impossible in most cases. This leads to inevitable “left hand not knowing what the right hand is doing” scenarios, thereby complicating the lives of marketers within an enterprise who must manually orchestrate the use of (and definition of) segments across an increasing number of apps. Worse, such behavior reinforces the perception that our products (even those that are otherwise “integrated”) don’t work well together.
This document explores a pattern that could help marketers manage their segments across a wide range of products that can span both cloud and on premise.
Some obvious use cases
- An unknown visitor arrives at a bespoke webpage and reveals their email address (either via global cookie, device fingerprinting, submitting a “more information” form, a redirect via campaign landing page, or just simple registration/provisioning). Webpage/app then inquires to a cloud endpoint: “what segments does xxx@yyy.com belong to?” and gets a response of 0-N segments. Webpage/app then renders segment-appropriate content for that visitor going-forward. Caching/expiring the response is entirely up to the webpage/app.
- A known visitor/contact arrives at a webpage served by an Oracle app that supports segment calculation natively (e.g. Commerce, Eloqua, Sites). The framework serving the webpage can then optionally inquire to a cloud endpoint: “what other segments does xxx@yyy.com belong to as calculated by other Oracle apps?” and gets a response of 0-N segments identifying both the segment name and the app that calculated it. The webpage framework can then use this information to further enrich local segment calculation or ignore it altogether.
- An application that cannot be extended to request REST services needs visitor/contact data that described pre-calculated segments for known visitors/contacts. This application could be for internet or intranet or whatever. Access to ICS can be assumed.
You will note that the above use cases assume that specifically *how* the segment was calculated is hidden from the requestor (as it should be as it is meant to be a service). As such, the requestor can simply trust the calculation and either leverage it or ignore it as appropriate. Think of segments exposed this way as a form of denormalization.
Trouble in Paradise
Everything would be fine if all of our segment-aware applications behaved in the same way and had exposed services around their segment engines. Unfortunately, nothing could be further from the truth. At the very minimum we have the following types of segment-aware applications:
- those that publicly (at least partially) expose their segment mechanism as services or APIs (e.g. Webcenter Sites)
- those that hide their segment services/APIs (e.g. Commerce)
- those that don’t have segment services/APIs at all (e.g. Eloqua)
- those that use other mechanisms (e.g. “categories”, “personas”)
Further, existing integrations offer very little with regard to segments. For example: The latest “Eloqua —> BlueKai” integration (as of June 2016) allows mapping a (known contact) segment/list to a BlueKai (anonymous visitor) category. But enrichment data is not shared with Eloqua — the expectation is that BlueKai will handle subsequent paid advertisements once Eloqua determines the right scenario (e.g. contact doesn’t respond to email). BlueKai likewise is unaware of why an Eloqua contact is “in segment”.
Worse, segment calculations are invariably proprietary. e.g.
- WC Sites: based on visitor attributes. Anonymous users are more difficult to ascertain and require custom front-end logic to do anything meaningful. (80%+ website visitors are anonymous)
- Eloqua: segments are just lists of contacts. Such lists can be created manually or based on contact’s attributes. Run-time behaviors are not supported. (100% of email recipients are known)
- Commerce: segments are (typically) based on visitor behaviors (note: while 80% of website visitors may be anonymous, 100% eventually become known once they complete their transaction)
- BICS: segments can be hierarchical. Very “chart of accounts”-like
One might come to the conclusion that “orchestration across all segment-aware apps can’t be done” and simply give up. I believe otherwise and further, that as more and more applications become segment-aware, the need for a single method of defining and using segments is becoming increasingly critical to marketers.
Segment “Management” not merely orchestration
As technologists, it is easy to figure out ways to “glue” things together — that’s our job. However, that is not only what is needed here. Rather we need to empower an organization’s marketing team to make sure that all their various web and mobile apps are using a common set of segments and their definitions — even though each app likely will have its own way of calculating a segment for any visitor. As such there is a need for a single management console.
One other observation: while applications such as Commerce, WC Sites, and others tout their ability to do dynamic segment calculation on-the-fly, many implementations and marketing teams treat segments as mostly “static” in that a marketing person or service representative places a known contact into one or more segments based on attributes (or behaviors). Consequently, the relationship rarely changes. Example: if I am a Gold Member I might eventually become a Platinum Member but such changes are rare and don’t happen daily. As such, for many use-cases, storing pre-calculated segments per known contact in a central repository can provide a sufficiently rich customer experience that the benefit of centrally managing outweighs any perceived negatives.
Rather than building our own custom app (which is still allowed under this pattern) I propose instead leveraging a new feature of WebCenter Sites v12 — its Visitor Services (a.k.a SVS). (see https://docs.oracle.com/middleware/1221/wcs/use/GUID-EA7FEA17-C9C3-483D-B246-2F88E2BA17CC.htm#WBCSU8599). Not only do we not have to build very much to complete the pattern, but SVS provides a rich environment for allowing marketers to design the rules for managing aggregating visitor attributes across a wide range of repositories. More to the point, using SVS to prove out the viability of the proposed pattern is a low-risk approach that is readily presentable.
Assumptions
- This pattern need only manage “static” segment calculations performed by various applications and stored in a central repository as “static”, pre-calculated values. Any real-time calculations (that perhaps build upon and enrich the static segment assignment) are to be performed by the application serving the webpage or mobile app.
- There will be a service endpoint that will allow querying on behalf of known visitors/contacts
- The service endpoint can also be queried to inquire as to the current list of enumerated segment names per application
- Applications that cannot expose their segment calculation mechanism to remote querying via REST (e.g. Eloqua) must observe the following rule when creating segments locally: in order to maintain synchronization with other apps across the enterprise, segments should ideally only ever be created based the value of a custom field per visitor. This field value will be populated by updates from the central repository. Ideally for end-users of the application it would be expressed in the GUI as an enumerated Multi-select field named “segments”.
- Example: Contact=michael@abc.com Segments=Gold,FrequentTraveler,CollegeEducatedMale.
The segment array payload
The service endpoint should return an aggregated lightweight profile for each visitor/contact styled like the following:
visitor_segments :
{
email : “msullivan@xyz.com”,
context: “commerceSite”, segments: [ “A”, “C” ],
context: “campaign2016”, segments: [ “B”, “D” ]
}
The segments array should be configured to be able to created/updated from any contributing system that is segment-aware. The segments array should be readable by any subscribing application.
This makes it possible for a consuming client to fetch and build logic around any combination of segments without losing the origin/original intent of segment. As newer systems are added as part of the integration, they just end up being new contexts and integration is streamlined.
Diagram
Outbound Features:
- For those apps that can efficiently request additional visitor attributes on-the-fly (e.g. being able to cache the payload response), a read-only, lightweight REST endpoint for querying single visitor records. Assume the app doing the querying has some sort of key to initiate the search, whether it be email, visitorid, or whatever.
- For those apps that have security or latency issues, a bulk mechanism to update visitor/contact records via export from Sites Visitor Services. One obvious model would be to use ICS for this. Note however that until such time that ICS supports batch processing, there will likely need to be a custom servlet deployed in the SVS Weblogic instance to handle the batch orchestration.
Optionally, as raw visitor attributes are aggregated via an aggregation template, this template can optionally call out the WC Sites Engage mechanism to calculate the segment based on the current visitor attribute values - Similar to the above, the template could also call out to any other segmentation engine as appropriate
Inbound Features:
- Any OOTB or custom providers as allowed for and supported by WC Sites
Final Thoughts
Ideally, such a service would be hosted “in the cloud” and as such, using Sites Visitor Services will not be a long-term solution. But that is not the point of this pattern anyway. The suggestion of using SVS was simply to “bootstrap” any POC so as to validate and tweak the pattern to your client’s particular use cases. Would love to hear your thoughts.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission