A2P SMS Traffic Tags: How to Design a Useful Taxonomy for Analyzing Quality, Costs, and Incidents

Why Delivery Statuses Are Not Enough

Delivery statuses are an important part of operational evidence, but they do not by themselves describe the context of a send. In SMS, status reports, transfer attempts, certain error causes, and retries related to handset availability are part of a technical cycle with several possible outcomes.

The same aggregated status can have different operational implications depending on the use case, criticality, destination classification, sender type, applied routing policy, or content version. Without these dimensions, a change in acceptance, reported statuses, or latency may be visible but difficult to attribute and investigate.

An A2P SMS tag taxonomy provides this context in a structured way. Its purpose is not to replace technical events or correlation identifiers, but to make it possible to segment them using stable, comparable, and auditable categories.

• Separate OTP traffic, transactional alerts, and consented campaigns.
• Distinguish critical from non-critical messages to prioritize operational response.
• Compare results by country or territory classification, logical routing policy, and template version.
• Prevent an aggregated decline or apparent improvement from concealing divergent behavior across segments.

Design Principle: Technical Identity, Operational Classification, and Personal Data Are Separate Layers

The first principle is to separate three categories that are often mixed together: technical identity for correlating events, operational classification for analyzing traffic, and personal data or sensitive content that should be minimized.

SMS architecture uses identifiers and reports to associate messages with technical events. These identifiers are useful for reconstructing a specific sequence, but they should not become the analytical taxonomy. Likewise, business categories are not necessarily part of network identifiers and should be managed as metadata belonging to the platform.

Operational classification should answer repeatable questions: what was intended to be sent, under which policy it was decided to send it, and in which segment it should be compared. Personal data, by contrast, should not be introduced into tags for analytical convenience.

• Technical identity: internal message identifier, correlation identifier, and protected event references.
• Pre-send classification: use case, criticality, destination classification, sender type, origin channel, campaign class, logical route, and template version.
• Observed outcome: acceptance, received status report, failure cause, timestamps, and calculated latency.
• Data to avoid: full MSISDN, SMS text, OTP, person's name, address, and recognizable account identifiers.

Minimum Fields and Optional Extensions for an Operational Taxonomy

The exact set depends on the operating model. The following is an adaptable operational proposal, not a set of fields prescribed by a technical standard. It should provide useful segmentation without creating an unmanageable combination of values.

A practical core can cover the purpose, priority, destination classification, origin, and logical decision associated with a send. Additional fields, such as campaign_class, provider_logical, or template_version, can be used where they are available and materially improve analysis.

It is advisable to retain classification tags alongside the send record and store observed outcomes as separate events or status fields with timestamps. This separation prevents a later observation from rewriting the original intent or decision.

• Core classification fields: use_case, criticality, destination_country, sender_type, origin_channel, and logical_route.
• Optional extensions: campaign_class, provider_logical, template_version, and taxonomy_version.
• use_case: operational purpose, such as otp, transactional_alert, or consented_marketing.
• criticality: business or operational priority, for example critical, high, standard, or low.
• destination_country: country or territory classification derived from the international numbering prefix or numbering plan. It is not the complete number and does not establish physical location, residence, nationality, or current operator; non-geographic numbering, portability, and other applicable cases may require careful interpretation.
• sender_type: sender classification used by operations. Values such as alphanumeric, long_number, or short_code may be useful where applicable, but permitted values depend on the environment, regulation, and origin configuration.
• origin_channel: system or channel that originated the send, such as api, smpp, portal, or system_event.
• campaign_class: optional operational grouping, such as lifecycle, service_notice, or consented_promotion; not a free-text name containing customer information. It may not be relevant to every flow and may be omitted where unnecessary or unavailable.

Logical Route, Provider Reference, and Taxonomy Governance

logical_route can represent a routing profile, policy, or other logical decision under operational control. It should not be used to claim a physical path, a final operator, or a network condition that has not been observed or cannot be verified.

provider_logical is an optional internal reference to a selected provider or logical capability. It represents the logical decision recorded by the organization, not a guarantee of the actual path taken across network segments or of quality at a destination.

Governance rules should be documented separately from individual field definitions. This keeps the taxonomy readable while preserving the controls needed for consistent historical analysis.

• Use stable internal values for logical_route and provider_logical while they remain active.
• Record configuration changes with an effective date, owner, and traceability so historical series do not combine different decisions under one value.
• Document each internal code's purpose and limitations.
• Limit access to mappings between internal references and real entities to teams that need them for operations, procurement, incident investigation, or applicable obligations.
• Do not place credentials, commercial terms, contractual information, or personal contact data in tags.
• Interpret routing tags together with observed events, timestamps, and the rest of the send context.

Distinguishing Pre-Send Decisions From Observed Outcomes

A pre-send decision tag describes the context available before the message is transmitted. For example, use_case=otp, criticality=critical, logical_route=priority_policy, and template_version=otp_v3 indicate how the send was classified or handled when it was created.

An observed outcome is generated afterward: acceptance_state, a received status report or reported state, failure_class, and timestamps. A DLR is a received report whose meaning and degree of confirmation depend on the interface, provider, status code, and technical context. It should not be treated as universally equivalent to confirmed delivery to a handset.

This distinction is essential for investigation. If a segment shows changes in reported statuses, it should be possible to check whether the routing policy, template version, destination mix, or traffic composition changed before attributing the change to a single cause.

• Before sending: use_case, criticality, destination_country, sender_type, origin_channel, campaign_class where applicable, logical_route, provider_logical where applicable, template_version where applicable, and taxonomy_version.
• After sending: acceptance_state, received DLR or reported state, failure_class, event_timestamp, and timestamps required to calculate latency.
• Analytically derived: latency windows, ratios by segment, and classification of uncertain outcomes.
• Do not rewrite the original classification using knowledge acquired after the send; add observed events or fields with their own date.

Controlled Values, Stable Names, and Useful Hierarchies

A tag is useful only if the same value means the same thing over time. Free-text values, inconsistent abbreviations, and definition changes without historical records reduce the ability to compare periods and weaken evidence during an incident.

Define a dictionary for each field: purpose, owner, permitted values, meaning, source, date introduced, retirement date, and transition rules. Naming should be readable by both machines and people, but should not depend on temporary names, specific campaigns, or changing commercial agreements.

Hierarchies can help retain detail without sacrificing comparability. For example, use_case can have a first-level family and a controlled subtype. If the detail does not change an analytical decision, it may not require a new dimension.

• Use values in a consistent format, such as lowercase letters and stable separators: transactional_alert or consented_marketing.
• Define each value precisely. Do not treat otp, one_time_password, and verification_code as synonyms unless the organization has explicitly documented that they represent the same category.
• Retain an unknown or unclassified value only when there is a clear policy for investigating and reducing it.
• Add new values through a documented request; do not reuse a retired value with a different meaning.
• Version the schema with taxonomy_version to interpret historical data correctly.

Example Schema for OTPs, Alerts, and Consented Campaigns

The following example shows an operations-oriented classification proposal. It is not intended to define universal categories and does not replace regulatory, contractual, or consent requirements applicable to each organization and destination.

The key is for tags to reflect configuration or classification facts known to the sender, rather than assumptions about the recipient or unverified claims about the network.

• OTP: use_case=otp; criticality=critical; campaign_class=authentication where used; template_version=otp_v3 where available; origin_channel=api.
• Transactional alert: use_case=transactional_alert; criticality=high; campaign_class=service_notice where used; template_version=alert_v2 where available; origin_channel=system_event.
• Consented campaign: use_case=marketing; criticality=standard; campaign_class=consented_promotion where used; template_version=promo_v5 where available; origin_channel=portal or api.
• In every case, use destination_country as a normalized numbering-plan classification, sender_type where applicable, logical_route according to the selected policy, provider_logical where used, and taxonomy_version in line with the current schema.

How to Analyze Acceptance, Status Reports, Latency, and Uncertain Outcomes

Tags make it possible to segment metrics, but they do not change the meaning of the evidence. Acceptance may indicate that a platform or segment has accepted a request. A DLR or other reported status is a report received within the technical SMS transfer cycle, and its meaning and level of confirmation depend on the interface, provider, status code, and technical context. Neither should be presented on its own as proof of human reading, conversion, or recipient action.

For analysis, always compare homogeneous segments. A decline in received reported statuses for critical OTP traffic to a particular destination classification under the same logical route is more investigable than a global average that combines campaigns, destinations, sender types, and different policies.

Latency requires an explicit definition. Document which timestamps are subtracted, the time zone in which they are normalized, which events are eligible, and how messages without a later event within the defined window are handled. Results without a received report or with incomplete information should remain uncertain, not be automatically reclassified as delivery or definitive failure.

• Analyze acceptance_state by use_case, destination_country, logical_route, and sender_type.
• Analyze received DLRs or reported states by cohorts with the same template, version, and period.
• Calculate latency only when the required timestamps are comparable and available.
• Separate failure_class from unknown or pending statuses.
• Retain denominators, observation window, metric definition, and taxonomy version in every report.