An Interaction in Omneo is a lightweight record of something a customer did that is not a purchase. Each interaction captures one action, in one channel, carrying a signal of positive, neutral, or negative. It is the catch-all activity record for anything that does not have its own dedicated model.
Where a Transaction records a purchase and a Visit records physical presence, an interaction records the smaller signals in between: a login, a product view, a form submission, a clienteling screen view. Any one of these on its own is minor. Together they build a picture of how a customer engages with a brand between purchases.
What an interaction captures
Every interaction is described by five required fields.
| Field | Description |
|---|
action | The kind of action that took place. One of broadcast, disclose, feedback, product, reach, refer, service, visit, view. |
channel | Where it happened. One of app, email, location, push, sms, social, support, website. |
signal | The sentiment of the action, as an integer. 1 is positive, 0 is neutral, -1 is negative. |
name | A human-readable label for the interaction, for example “Viewed product page”. |
namespace | A handle you define to group related interactions, for example web-engagement or clienteling. |
description, url, duration, latitude and longitude, interacted_at (when the action happened, if not now), tags, and a free-form meta array.
The signal field is what makes interactions useful for sentiment over time. A run of negative-signal support interactions followed by a positive-signal one tells a story that no single record could.
The catch-all role
Interactions exist so that meaningful customer activity has somewhere to live even when it does not justify its own model. Reach for an interaction when an event is worth remembering but is too small or too varied to model on its own.
Do not use an interaction where a dedicated model already exists. Those models carry richer, purpose-built fields and their own reporting, and duplicating them as interactions splits the same activity across two places.
| Record this as | Not as an interaction |
|---|
| A page view, product view, login, or form submission | A purchase, which is a Transaction |
| A generic engagement event from any channel | A store visit or appointment, which is a Visit |
| A clienteling screen view or staff-assisted action | A rating, NPS, or CSAT response, which is a Rating |
| Any signal that has no model of its own | A field change on a profile, which is captured by the profile audit log |
Linking to other models
Interactions are deliberately flexible. A single interaction can link to almost any other object in Omneo, which makes it a connecting record as much as an activity record. Use this to attribute an interaction to where, what, and who it involved.
| Link | Field | Example |
|---|
| Location | location_id | A product view in a specific store |
| Product | product_id | A view or enquiry about a product |
| Product variant | product_variant_id | Interest in a specific size or colour |
| Product category | product_category_id | Browsing a category |
| Staff | staff_id | The staff member who assisted, as a profile |
| Organisation | organisation_id | A B2B account the action belongs to |
interacted_type to the object type and interacted_id to its ID. Supported types include transaction, order, appointment, questionnaire_submission, rating, reward, benefit, list, and many more. This is how an interaction ties otherwise separate records together, for example linking a feedback interaction to the questionnaire_submission that produced it.
Recording an interaction
How you record an interaction depends on how much you know about the customer.
| Context | Route | When to use |
|---|
| Server-side integration that knows only an identifier | Global POST /v3/interactions | You hold a system identity, email, or mobile, but not the Omneo profile ID. Supply an identifier and Omneo resolves it to the right profile. |
| Customer-facing experience with a known profile | Profile-scoped POST /v3/profiles/{profile}/interactions | A logged-in session or any context where you already hold the profile, such as a loyalty app or clienteling screen. |
Interactions are event records
Treat an interaction as a record of a moment that has passed. In normal use you create it and move on; you do not go back and change it. This is what makes a profile’s interaction history a reliable timeline.
Interactions are not immutable in the way a Transaction is. The API does expose edit and delete operations, each behind its own permission scope, for correcting a mistake or honouring a deletion request. Use them for correction, not as part of normal activity recording.
Convenient, not creepy
Interactions make it easy to record a lot of activity, so the question is not what you can track but what you should.
Only record interactions a customer would expect and find useful. The test is simple: if the customer saw the record, would it feel convenient, or creepy? Track the actions that help you serve them better, and leave the rest.
- A login on a website or app
- A view of a page or a product
- A view within a clienteling session
- A submission of a third-party form
Using interactions
Interactions earn their place in two ways.
- Reporting: browse interactions across all profiles with the global Interactions API to understand engagement, channel mix, and sentiment trends alongside transaction data.
- Incentives and gamification: each new interaction fires an
interaction.created event, which is available as a Reaction trigger. Use it to award points, issue a benefit, or progress an achievement when a customer takes a tracked action, for example rewarding the first product review of the month.
