Help · Analytics

Metrics

A metric is a kind of thing that happens. Placed Order. Viewed Product. Opened Email. The Metrics page is the catalog of every one of them your store has recorded — everything that can be tracked to a profile, from your store, from the integrations you wire up, and from the email you send.

Nothing has to be registered or declared. A metric appears here the first time an event with that name arrives.

Ordered Product is a metric you can expect to see appear on its own, from your store, the first time an order arrives. It is one event per product on an order, recorded alongside Placed Order, and it is what rules about a particular product are built on. The Narrowing by property page explains it.

Cancelled Order appears the first time you cancel an order in your store.

The parcel metrics arrive the same way, from your carrier by way of your store — Label Printed, Label Purchased, Confirmed Shipment, In Transit, Out for Delivery, Attempted Delivery, Ready for Pickup, Delivered Shipment and Shipment Failure. Not every carrier reports every step, and some report none at all, so a parcel metric that has never fired here is a fact about what your carrier sends rather than about your orders. Delivered Shipment is the parcel; Delivered, under "From Carpe Messaging", is an email the email provider accepted. Two different things, two different names.

The catalog

Two columns: Metric and Last activity.

In front of every metric name is a small mark saying whose record this is. Hover it and it names itself:

The last two share a mark, and that is deliberate rather than an oversight: the mark answers which system made this record, and both of these were made by this app. The words answer whose thing it was — and a form is yours, so it never says "from Carpe Messaging".

A metric that has never fired still belongs here — it is a thing your store can be counted by — and reads No activity yet.

One line on the page is worth reading twice. Last activity reflects every event the app holds. The charts behind these rows count profiles with a verified identity only. So a metric can say "last activity: today" and open onto a chart with less in it, and that is the reason why, not a fault.

If you have wired up an integration that mints an enormous number of metric names, the page shows the first several hundred of them and says so. Metrics from your store and from the app are always shown in full. A very long list is usually a sign that the integration is naming events after values rather than categories.

Opening a metric

Click a metric for its own page, with two tabs: Chart and Activity. The tab you are on rides the address, so Back returns you to what you were reading.

The chart

Three controls:

• Date range — last 30, 90, or 365 days.
• Group by — day, week, or month.
• Measurement — Total (every event), Unique profiles (how many different profiles), or Value (the money on the event, where it carries any).

Buckets are cut in your store's time zone, the same clock every date in this app uses. Days start when your store's day starts.

Under the chart, Show the numbers opens the same data as a table — Starting, Total, Unique profiles, Value — so nothing is reachable only by hovering. A window with nothing in it says no activity in this range, which is different news from a metric that has never fired at all.

A few honest notes render where they apply:

• The first and last points can cover part of a week or month, because a range is cut at an instant rather than at a calendar boundary.
• Apple Mail opens are overstated by Mail Privacy Protection, which fetches images before anyone reads the message. Treat opens as directional.
• Delivery outcomes can move. A later outcome replaces an earlier one, so mail marked as spam counts on the day it was reported rather than the day it arrived, and mail that bounces after being delivered leaves the delivered count — which means a day you already read can go down.
• Every number here counts profiles with a verified identity only — the same profiles your segments are built from.

The activity feed

The feed is shaped to the metric.

For the app's own email metrics it is a flat table: Profile, Email, and When, plus Subject and Campaign where the message carried them, and the Link for a click. Name and email are separate columns on purpose — two profiles can share a name, and the address is what tells you which one you are looking at.

For metrics from your store or an integration, each row opens to show everything the event carried. A second stamp, Received by us, appears only when a record reached the app more than a minute after it happened — which is exactly when a number here can differ from the same number in your Shopify admin, and the reason why.

Removing a metric

You can remove any metric you brought here: one your own integration posts, and one that arrived on an import of another tool's history. That covers the long tail of names a migration leaves behind, which is usually why you are here.

You cannot remove a metric that is your store's own record — orders and page views as they happen, your forms, the order history we read back from Shopify when you connected, and the app's own record of what it sent. Those would simply come back on the next order, the next page view or the next time we read your store, so removing them would promise something that undoes itself by tomorrow.

Removing works by name. If the same name arrived both ways you brought here — your integration posts Placed Order and an import also carried it — removing it removes both. The rows that are your store's own record keep counting, under the same name, and the Metrics page still shows them.

Removing is the owner's decision alone, and you confirm it by typing the metric's exact name. Before you do, the screen tells you what it will cost:

• how many events it will delete, and the dates they span;
• which segments use it, and which way they will move. This is the part that surprises people: a removed metric behaves as if it never existed, so a segment that used it to leave people out stops leaving them out, and those audiences can grow;
• which campaigns already reference it. Campaigns already sending keep the audience they locked in when they started. Campaigns that are armed but have not started block the removal — disarm them or let them send first, because their audience is worked out when they begin.

What happens when you confirm: the metric stops counting straight away and disappears from the catalog, the charts, and the feeds. It also disappears from the segment builder — neither the metric nor the properties it carried are offered any more, because a rule built on it could not answer. New events arriving under that name are turned away until you restore it — from your integration, and on the next import too, which is reported on the import's own page rather than passed over in silence. Rules that already reference it match nobody, including negations — which is the "exclusions stop excluding" effect above.

The events themselves are kept for at least 30 days, then deleted. Until they are deleted, Restore in the Removed metrics section brings back everything that was here: the history the metric already had comes back whole. What it does not do is fetch the events an import turned away while the metric was removed — those were never written here, so restoring cannot find them. Events turned away while it was removed are not offered again by a later import. After the events are deleted, the only thing left to lift is the block on the name — Allow this name again lets new events in from that point on, and the app says plainly that it does not bring the old ones back.

Removed metrics sit in their own section at the bottom of the catalog, with the day each was removed and what happens to it next.