Before starting an mtribes integration, first think about what you’d like to control and personalize in your application. This could range from the color of a button to an entire page of content.
Once you've determined which elements or components to control, it's time to model them in mtribes.
We use the term modeling as a high-level definition of app components you can control through mtribes. How you design and develop these components is up to you, using your preferred tools and development practices.
To support a broad range of platforms, we provide three simple building blocks to model with. These are collectively referred to as templates.
- Collections - group Experiences and Sections within a common scope
- Experiences - deliver personalized control over in-app components
- Sections - deliver personalized lists of Experiences
Let's dive deeper into each template type, looking at how and when to use each one.
As a backdrop we'll work through an example of a video-on-demand (VOD) store, and model the homepage. This example provides a high-level overview of this VOD store integration, with a focus on the modeling section.
A top-level logical grouping of related Experiences and Sections.
Collections offer a place to formulate a set of related Experiences and Sections.
Specific pages or screens of an app are a common Collection target, but cross-cutting domains such as "navigation" or "onboarding" would also make sense.
Let's start by creating a Collection to represent our
Homepage. We'll place it
A way to personalize and control a specific component in your codebase for an active user.
An Experience is the most granular entity you can model with. It maps directly to specific components being personalized in your app.
Once integrated, an Experience will control whether a component should be on or off for the current user, and when on, what personalized configuration it should be fed.
The configuration part is powerful. Experience templates allow you to define properties from a range of property types, sculpting the contract to meet the use case of the component it controls.
With our Collection in place, we'll create a
Hero Experience with an image URL
property. This will sit in the Experience library under a
Once you've created an Experience in your library, you can add a reference to it from any Collection.
We'll reference the
Hero Experience from our
Homepage Collection with the
purpose of controlling the
Movie Hero component in our app.
A list of dynamically ordered Experiences, chosen by a scheduler from a predefined set and delivered at runtime to your app.
When an Experience is referenced directly under a Collection, it best represents a fixed component in your application, like a button, video player or in our example a movie hero.
While fixed Experiences cover many use cases, the ability for a scheduler to pick from a set of Experience types, define these in a list, and choose their order, can open up many more opportunities.
We designed Sections to offer these capabilities.
When modeling a Section, you decide which Experiences a scheduler can choose from. You can also restrict the maximum number of Experience instances they can add.
You define Sections inside a Collection template by dragging one across from the right-hand menu.
To continue our example, we'll create a
Body Section that allows a scheduler
to choose from
Promo Experiences. We limit the
scheduler to a maximum of 10 Experience instances.
Once integrated into the VOD store app, a scheduler can then decide which of the corresponding components will appear in the body of the homepage, how many of each component there should be, in which order to present them, and customize each to segments of the audience.