# Measure Apple Messages business outcomes

Use Bird's [channel metrics](/docs/guides/apple-messages/analytics) to measure messaging activity and processing. Use the system that owns the order, booking, payment, or case to establish the business result.

A message's **Sent** status confirms Apple's gateway acceptance. A form answer or selected time records a customer interaction. Neither establishes that a business action completed.

## Define the result before reporting it

Choose a result your source system can confirm, such as a reservation created, an order paid, or a service case resolved. Write down the timestamp, record identifier, and conditions that qualify the result.

For an appointment, distinguish these observations:

| Observation              | Evidence                                            |
| ------------------------ | --------------------------------------------------- |
| Time options offered     | The outgoing message record.                        |
| Customer selected a time | The incoming native response.                       |
| Appointment reserved     | The booking system's successful reservation record. |
| Confirmation sent        | The separate outgoing confirmation message.         |
| Appointment attended     | The service team's attendance record, if collected. |

Choose a denominator that answers your question. For example, reservations divided by customers offered times measures a different stage from reservations divided by received time selections. Name the period and exclusions with the result.

## Connect the records

Retain a case or operation reference alongside the Bird conversation and message IDs in your integration. For API sends, use supported `metadata` or reporting labels according to the [send-message contract](/docs/api/reference/create-amb-message). A reporting label does not change permission, suppression, or retry behavior.

Use a reference from your own system rather than putting customer secrets in a URL or message tag. Record which system supplied each timestamp and result. Apply your retention and access rules to the joined data.

## Handle repeats and late outcomes

Deduplicate webhook deliveries and business actions separately. A repeated delivery of the same event must not create a second reservation. A customer's second, intentional request may represent a different operation.

Reconcile actions that remain uncertain after a timeout. Allow late provider results to update the original operation instead of counting them as a new conversion. Include cancellations and reversals when the reporting question requires them.

## Interpret the report honestly

A closed conversation is a customer lifecycle event; it is not a resolution score. A shorter first response does not prove that the answer was correct. An absent device read receipt cannot be filled in by treating gateway acceptance as a read.

Compare outcomes by the supported entry-point intent or your own case categories when useful. Review unresolved requests and failed paths alongside successful outcomes. Keep this business report distinct from Bird's messaging dashboard so readers can see what each number establishes.