Attribute Use Cases
Attributes are structured labels for campaigns, mailings, and scenarios. Unlike free-form tags, an attribute value is selected from a predefined list and is validated. Entities inherit values along the Campaign — Scenario — Mailing chain, and attributes are available in search, segmentation, templates, and the API.
Below are attribute use cases, from keeping lists organized to passing data to external systems. The examples are illustrative and easily adaptable to a specific business.
Entity tagging and search
Problem. Campaigns and mailings accumulate, and finding the right group in shared lists becomes difficult: different employees use different wording, and entities of different projects get mixed up.
Solution. An attribute defines a unified set of values for tagging. Create an attribute Communication type with the values Targeting, Notification, Service — and each employee selects the type from the list when creating a mailing instead of inventing their own wording. In the mailing, campaign, and scenario lists, entities are filtered by attribute value, and segments and reports are built by communication type.
Similar problems are solved the same way:
- Product lines — tagging mailings by product categories;
- Multiple brands or clients in one account — the
Clientattribute separates campaigns by brand; - Company structure — the
Departmentattribute separates marketing campaigns from sales campaigns.
Unlike tags, attributes do not allow a "random" value: the user selects from a predefined list, so tagging is always uniform. The value is inherited along the Campaign — Scenario — Mailing chain: tag a campaign once, and the mailings inside it are considered tagged.
Completeness and format validation
Problem. Each entity must carry certain data — for example, an owner and a ticket number — and values with an incorrect format must not enter the system.
Solution. A required attribute Owner with the values Ivanov, Petrova, Sidorova: the entity cannot be saved without a selected value. Configure the Ticket number attribute with the Limit character count and Use a regular expression options to check the length and format of the entry.
How format checks work:
-
A regular expression validates the entered attribute value against a pattern. The pattern describes the allowed entry format — for example,
/[A-Z]{2}-\d{4}/requires a value likeAB-1234. An entity cannot accept a value that does not match the pattern: when saving a campaign, mailing, or scenario with such a value, the platform rejects the save. -
The character count limit sets the maximum length of the value. It is useful when the attribute value is passed to an external system with a strict field length limit (for example, a contract number of up to 20 characters), or when the value is output in a template and must not bloat the content. A value that exceeds the limit is not accepted.
Both checks apply to the values entered by the user. If a value is selected from a predefined list, it already conforms to the specified format, so the regular expression and the length limit are especially useful when the user is allowed to add new values while editing an entity.
The Disable attribute editing in active entities option blocks changing values after activation, and the default value is inserted automatically if the user has not selected their own.
Attributes control data completeness and format but do not govern launching: permission to launch an entity is configured with roles and access groups, not with attributes.
Audience selection
Tagging entities with attributes serves as a basis for profile selection.
Segmentation. In segmentation by activity, profiles are selected by participation in mailings with a specific attribute value. For example, the segment "received a targeted mailing" is built by the attribute Communication type = Targeting — without manually listing mailings in the condition. Such a segment automatically includes new mailings with this attribute and helps control communication frequency: for example, select subscribers who received several service messages in a row, or avoid sending targeted messages to those who recently received promotional ones.
Control groups. In global control group settings, entities with a specific attribute value are excluded — for example, service mailings do not participate in the effectiveness calculation. In the local control group (LCG) settings, a filter by attribute values builds rules for excluding profiles by the attributes of specific campaigns, scenarios, and mailings.
Content personalization
Problem. Insert into a template or link a value that a marketer sets once at the entity level and that changes from launch to launch — for example, a landing page link with UTM tags. The template remains a single one: no need to edit the layout or copy it for each campaign.
Solution. Create an attribute, for example Promo link, and specify its API name — it is used in variables. The value is set on the entity when it is created or modified: manually by a marketer or via the API. For mailings, the value does not have to be duplicated — it is inherited from the campaign or scenario.
Insert the variable into the button link of the template:
https://example.com/promo?utm_source=news&utm_campaign={attribute_value("promo_url")}
When sending, the platform substitutes the attribute value set on the entity (or inherited) into it. For example, a single promo template with the "More about the offer" button is used for all launches, while the landing page address with UTM tags changes from campaign to campaign: a link with the spring_2026 tag is set in a campaign — the button leads to it; the next launch gets a different tag, with no template editing.
The "Attribute value" variable is inserted into content and into the URL. The attribute value can be selected in Viber, WhatsApp, Notify, and MAX templates. For more about the variable, see the Attribute settings article.
An attribute stores one value per entity — it is the same for all recipients of a mailing. This mechanism suits content shared across the whole campaign (links, UTM tags, promo identifiers) and is not suitable for personal data: a unique promo code, a subscriber name, or their balance is substituted from profile fields, Market data, or a loyalty program.
Integration with external systems
Problem. An external system (CRM, BI) passes entity tagging to the platform and receives attribute values back — for reporting or automation.
Solution. For each attribute, fill in the API name — the attribute is identified by it in requests. Parameters with the attribute name and value are available in platform API requests, and entity list requests return attribute values in the response. For more about the API, see the corresponding section.
For example, to get the list of mailings with a specific attribute value, send a POST request to https://example.com/api/v1.1/campaigns/list:
{
"attributes": {
"communication_type": {
"options": ["Targeting"]
}
}
}
The platform will return the mailings whose communication_type attribute equals Targeting:
{
"data": [
{
"id": 130,
"name": "Autumn Sales",
"type": "broadcast",
"is_active": false,
"attributes": {
"communication_type": "Targeting"
}
},
{
"id": 131,
"name": "20% Off Annual Subscription",
"type": "broadcast",
"is_active": false,
"attributes": {
"communication_type": "Targeting"
}
}
],
"error": 0,
"error_text": "Successful operation",
"total_count": 2
}
The full description of the request and response parameters is in the developer documentation.
In custom channel pipelines, the entity attribute value is available via the $getAttributeValue(message_id, "attribute_id") function — for example, to pass a parameter set at the campaign or mailing level to an external API.
Attributes can also be updated for already completed mailings — tagging does not "freeze" after a mailing ends and remains available for refinement.