To achieve all this, we have defined a set of steps and processes - Occtoo bloks. The bloks are the DNA of what Occtoo is and how it works. You can view Occtoo documentation here.
Here’s how you can move to Experience data ...To make it easy to re-use and repurpose data, and also easy for your frontends to consume data, you must have unified Experience Data. Your frontends should be built as thin as possible, focusing on the experience, look & feel (the design and experience of the app), and it should consume the data via real-time APIs (Occtoo Destinations) making data and frontend truly decoupled.
When new Experience data sets (Occtoo Segments) are released, it becomes easy to expose this data via real-time experience APIs (Occtoo Destinations) ready to perform in any context or provide relevance in any micro-moment. This is something that is going to be needed repeatedly, over time, with new data points, especially as we are at the beginning of an app explosion.
One of the challenges when working with data is to know where to draw the data enrichment line; you must understand which Enterprise data is needed to be transformed from an Enterprise state (slow data) into an Experience state (fast, geo-scaled data), aka turned into Experience data to generate a customer experience. The integrity of the Enterprise data, “single” domain data (the product data, customer data, transactional data, etc.) must also be respected during the enrichment phase for maximum flexibility and adaptability (smooth & efficient enrichment/creation process).
This approach will maximize reusability and efficiency in a content creation process. If you don´t respect this, the risk is that you end up creating yet another hard-to-use and ridged “one-off frontend-specific” data silo. Continuing the never-ending movement of data between databases, and letting the last data silo dictate which data is accessible in a frontend experience. You should of course as said…Instead, turn the Enterprise data into Experience data, making it easy to reuse and repurpose, and easy for any frontend to consume.
To do this the data must be stripped down into its simplest form, making it free from its old data model (data shape); in Occtoo this is a simple key-value format (Occtoo Source). When the data is free from its old data shape (format), it’s easy to repurpose and reuse in any way or to combine data attributes from single-domain data sources into a multi-domain data state (Occtoo Cards). Once the data is defined in the Occtoo Cards it is easy to create or “weave” into Experience data (Occtoo Segment). New Experience data sets (data tailored to a specific context and unique purpose) can now be exposed as real-time Experience APIs (Occtoo Destinations), with built-in documentation on how to consume the data and endpoints.
We are moving into a new state where the number of screens/frontends are just exploding. So, make sure not to get comfortable in the old state, building in the old traditional way. To excel in this new era, you must be able to easily add and combine new data fields or content attributes and share this via real-time APIs. You cannot afford to be restrained by a last silo database approach for frontend experiences built in old technology with an old mind-set.
Onboard – Occtoo Source
Where is the data I need?
Transferring data into Occtoo is very easy since Occtoo has no model or format that the data needs to fit to. The process of on-boarding data is handled by Occtoo Source. This blok makes sure the data is on-boarded to Occtoo and accessible across different data domains. To assist developers and integration professionals in on-boarding data through the Source Blok, Occtoo provides a set of open-source tools and code examples.
Unify & Relate – Occtoo Card
What attributes from my source do I need, and what do I need to combine?
To make the data more intelligent (unify across data domains) you can use relations and mappings. This is achieved by using a combination of business rules, tags, faceting,. Card Blok is responsible for the mapping of the on-boarded data and, if needed, enriching it further on-boarding of any 3rd party data sources. This is where you define your on-boarded data and end up with a unified dataset that can be used to power your new digital experiences.
Activate – Occtoo Segment
To build relevant experiences, you need to present just the right products matched with the right content to the end customers. You can do this by shaping the experience based on the customer and unifying it with their current context. For customers, we might have information such as their gender, interest, or similar information typically contained within a CRM or CDP. Context could be dependent on things such as the device, location, weather, or event: this is information we can get from the user session variables. In Occtoo, the activation of these data points is configured in the Occtoo Segment blok, this is where you define what data the experience should consist of.
Speed & Scale - Occtoo Destination (direct, engage, publish, expose)
Who, how & when is my data consumed (UI/UX, API, Feeds)?
Building new and fast digital experiences requires the data to be available anywhere around the world within milliseconds, pushed to various platforms in the correct format and fashion. This is the task for the Occtoo Destination blok. Occtoo can scale any data around the world when needed, giving developers access to data as though it was local for their applications. The data is geographically scaled, with millisecond response times, fully documented (swagger), and ready for the front-end developers to start using right away.
