> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/understand-mediarithmics/how-mediarithmics-works.md). # How mediarithmics works How an instance is organised, where your data lives, how it is modelled, and how it flows in and out. ## Your goal Understand how the platform is put together before you plan an integration: how your instance is organised, where your data is stored, how that data is modelled, how it gets in and out, and where your own logic can be plugged in. By the end of this page you should be able to place any later setup task - a schema, a channel, a segment, a feed - inside a structure you already recognise. {% hint style="info" %} Nothing on this page requires access to the platform. If you already have access and simply want to find your way around the interface, read [Navigate the platform](/setup-and-monitor/understand-mediarithmics/navigate-the-platform.md) instead. {% endhint %} ## How your instance is organised Your work happens inside an **organisation**: a sandboxed set of objects, permissions, datamarts, and settings. Organisations nest - an organisation can have one parent and several children - and the top-level organisation of a hierarchy is a **community**, where a few settings such as single sign-on live. Settings and objects are not systematically inherited from a parent organisation, so what matters in practice is which organisation you are working in. [Prerequisites - Organisation and Datamart](/setup-and-monitor/plan-and-integrate/set-up-the-environment/prerequisites-organisation-and-datamart.md#organisations-and-communities) defines both objects and sets out what to check before you configure anything. ## Where your data lives: the datamart All user data captured or computed by the platform ends up in a special database called a **datamart**. It is more than a traditional database: the engine behind it is built for data-driven marketing, and serves real-time queries and analytics over large volumes from a single store rather than from copies scattered across tools. That is what makes one-to-one use cases possible - real-time customisation of the user experience, audience segmentation, funnel analytics, campaign analytics. A datamart does not have to hold the data it serves. It can instead read from your own cloud data warehouse and treat that as the source of truth, with the computation running there. That choice is the datamart's **deployment mode**, and it belongs with the earliest decisions of a project: see [Choose your deployment mode](/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md). Full definition, including what a datamart is technically: [Prerequisites - Organisation and Datamart](/setup-and-monitor/plan-and-integrate/set-up-the-environment/prerequisites-organisation-and-datamart.md#datamarts). ## How your data is modelled: the UserPoint Information in a datamart is primarily stored as a **graph**: nodes hold pieces of information, and links between them represent relationships. Take a user who visits a website carrying a tracker connected to the platform. At the end of the visit, three nodes exist in the datamart: * One node representing the user. * One node representing the visit - the site, the date, the visit duration, pageviews, products in the basket, and so on. * One node representing the device that was used. The node representing the user is drawn as a pinpoint, and that is what it is: a **UserPoint** is the central pinpoint that connects every piece of information collected about one user. It is a 360° view of a single user, online and offline.
A UserPoint at the centre, linked to content, identifiers, choices and computed fields

A UserPoint connects identifiers and describing content for one user

Each UserPoint has a **UserPoint ID** that identifies it uniquely in mediarithmics, alongside its other identifiers. ### Identifiers on a UserPoint It matters to distinguish nodes that *identify* a user from nodes that *describe* one. There are three types of user identifier: | Identifier | What it is | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **UserAccount ID** | The identifier of a registered user, coming from a registration system external to mediarithmics - a CRM, a loyalty program, an authentication system. It is composed of a character string and a compartment ID representing that registration system. | | **UserEmail** | An identifier based on the user's email address. It is usually derived from the email by a hash function such as MD5 or SHA-256. | | **UserDeviceTechnicalId** | The identifier of a device: a cookie, a network ID, a mobile ID. | ### Information attached to a UserPoint The describing content of a UserPoint is made up of data elements that each give a different point of view on the user: * **UserActivity** - an interaction with the user, online or offline. It can be the summary of an online visit, the detailed content of an in-store purchase, the summary of a call to a call centre, or a campaign interaction such as an opened email or a click on a banner. A UserActivity can contain a list of events, an **event** being the most granular level of interaction, defined by a name and a set of custom properties. For each user, activities are ordered in a timeline. * **UserProfile** - a summary of timeless information about the user, such as first name, last name, birth date, address, or age. It is usually imported from an existing information system such as a CRM or a login database, and carries information like contact details, preferences, loyalty program status, or newsletter subscriptions. * **UserSegment** - the fact that the user belongs to a particular group of users, such as an audience segment. A UserPoint carries one UserSegment node per segment the user belongs to. * **UserChoice** - the choice a user has made regarding data privacy and the data processing declared by your organisation. The platform uses this to adapt application behaviour to the user's choices automatically. * **UserScore** - data calculated dynamically to provide predictive information about a user, connected to a Machine Learning Function. A UserScore can predict expected lifetime value, churn risk, age, or gender, for example. ## How data flows in and out Everything you will set up later sits somewhere on this path. ```mermaid flowchart LR subgraph collect["Collect"] RT["Real-time tracking
tag, apps, tracking API"] BATCH["Batch imports
activities, profiles, segments,
identifiers, user choices"] WH["Data warehouse sync"] end DM[("Datamart")] subgraph use["Use"] Q["Query and analyse"] SEG["Audience segments"] AUTO["Automations"] EXP["Exports and replication"] end RT --> DM BATCH --> DM WH --> DM DM --> Q DM --> SEG DM --> AUTO DM --> EXP SEG --> DEST["Third-party destinations"] AUTO --> DEST ``` Data arrives in real time from tracked sites and apps or from the tracking API, in batches from your information systems, or through a synchronisation with your data warehouse. Once it is in the datamart, the same store serves querying and analytics, audience segmentation, automated orchestrations, and exports back out to third-party systems. The diagram above describes a datamart that holds its own data. Where the warehouse is the source of truth instead, the same collection routes exist but come to rest in the warehouse, and segmentation and identity resolution execute there. [Choose your deployment mode](/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md) sets out the difference. ## How the platform is extended All platform services are directly manageable and consumable through APIs. Beyond those standard capabilities, the platform is also a computing infrastructure that can host your own algorithms, packaged as **plugins**. A plugin is a bundle of code and data defining the behaviour of a live function hosted in the mediarithmics cloud. It can be developed in any programming language, though latency requirements make some languages more suitable than others. Plugins exist for activity enrichment, audience feeds, predictive data, ad and email rendering, attribution, custom automation actions, and computed fields. The plugin model - and the full list of types - is in [Plugin architecture](/setup-and-monitor/extend-the-platform/plugin-architecture.md). The platform also operates at the heart of an open ecosystem, offering connections with many partners across analytics tools, messaging solutions, personalisation solutions, prediction tools, advertising networks, and audience monetisation. ## What to set up next With the structure in mind, the setup work ahead of you falls into a small number of jobs: {% stepper %} {% step %} ### Frame the project and prepare the environment Agree on what you are building, then get an organisation and a datamart ready for it. [Frame your CDP project](/setup-and-monitor/plan-and-integrate/frame-your-cdp-project.md) · [Set up the environment](/setup-and-monitor/plan-and-integrate/set-up-the-environment.md) {% endstep %} {% step %} ### Design your data model Decide which data you collect and which of it needs to be indexed so you can query and segment on it. [Design your data model & schema](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema.md) {% endstep %} {% step %} ### Collect your data Connect your real-time sources, your batch imports, and your data warehouse. [Collect data in real time](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time.md) · [Import data in batch](/setup-and-monitor/collect-and-manage-your-data/import-data-in-batch.md) · [Sync with your data warehouse](/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse.md) {% endstep %} {% step %} ### Operate and monitor Query your datamart, watch ingestion, and build the dashboards your teams need. [Query your datamart](/setup-and-monitor/operate-and-monitor/query-your-datamart.md) · [Monitor data ingestion](/setup-and-monitor/operate-and-monitor/monitor-data-ingestion.md) · [Create a custom dashboard](/setup-and-monitor/operate-and-monitor/create-a-custom-dashboard.md) {% endstep %} {% endstepper %} ## Related pages
Platform overviewWhat the platform is for, and who works in it.Platform overview
Navigate the platformFind your way around the applications, the menus, and search.Navigate the platform
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.mediarithmics.io/setup-and-monitor/understand-mediarithmics/how-mediarithmics-works.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.