> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Return Rate by Bring Product Code, Bring > Return Rate by Bring Product Code for Bring stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Cross-Channel: Revenue at Risk](/nerve-centre/overview#card-classes-explained) ## At a glance > Return rate split by the Bring product code each outbound parcel shipped on, over the trailing 30 days against the prior 30 days. It answers a question a blended store-wide return rate hides: do parcels sent on one Bring service come back more often than another? A high return rate concentrated on a single product code points at the delivery experience, not just the goods. | | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | For each Bring outbound product code: `COUNT(orders with an inbound return consignment) / COUNT(outbound orders shipped on that product code)` over the rolling 30-day window. Each order is attributed to the product code of its original outbound Bring consignment. | | **Data source** | Store order and refund / return feed (Shopify returns, BigCommerce RMA, Adobe Commerce credit memos) joined to the Bring Booking API outbound consignment (which carries the product code, for example `5000` Pakke til hentested, `5800` Pakke levert hjem, `0340` Bedriftspakke) and any inbound Bring Retur consignment booked against the same order. | | **Cross-channel join** | Returns are counted regardless of which sales surface the order came from; the split is by Bring product code, not by channel. A marketplace order and a D2C order shipped on the same code land in the same bucket. | | **Bring product scope** | All outbound Bring products in use. Common Norwegian codes: Pakke til hentested (Mypack Collect, pickup-point), Pakke levert hjem (home delivery), Bedriftspakke (business-to-business parcel), plus Nordic export products. Each is reported as its own row. | | **Return definition** | An order is "returned" if a refund / credit memo is raised OR a Bring Retur inbound consignment is booked against it, whichever the store records. Partial returns count once at the order level. | | **Time window** | `30D vsP` (rolling 30 days, compared with the previous 30 days). Returns lag the original sale by days to weeks, so a 30-day window is the shortest that gives a stable read; the vsP comparison flags drift. | | **Alert trigger** | `>8% on any product`. The alert fires per product code, not on the blended average, so a problem isolated to one Bring service is caught even when the store-wide rate looks healthy. | | **Roles** | owner, operations | ## Calculation The card joins three things per order: the outbound Bring consignment (which carries the product code), the store's return / refund record, and any inbound Bring Retur consignment. For each product code it divides the count of orders that came back by the count of orders shipped on that code in the window. The subtlety is denominator timing. Returns arrive late, so an order shipped on day 28 of the window has barely had time to come back, while an order shipped on day 1 has had a month. The card uses a shipped-in-period denominator (orders despatched in the window) rather than a returned-in-period numerator matched to a different cohort, and reports the vsP change so you can see the trend even though the absolute rate for the most recent days is still maturing. Bring product codes are read from the outbound consignment booked through the Bring Booking API; the code is stable from label generation, so reclassification after despatch does not move an order between rows. Calculated automatically from your Bring and store-order data. See the At a glance summary above and the worked example below. ## Worked example The same Oslo outdoor-apparel brand, around 1,900 outbound orders per week, multi-channel. Reading taken at 08:00 CET on 14 Apr 26 for the trailing 30 days (15 Mar 26 to 13 Apr 26). | Bring product code | Orders shipped (30D) | Orders returned | Return rate | vsP | | ------------------------------------------ | -------------------- | --------------- | ----------- | ------------ | | Pakke til hentested (Mypack Collect, 5000) | 5,420 | 487 | 9.0% | +1.8 pts | | Pakke levert hjem (home delivery, 5800) | 1,930 | 116 | 6.0% | +0.2 pts | | Bedriftspakke (B2B, 0340) | 410 | 12 | 2.9% | -0.3 pts | | Nordic export (SE / DK / FI) | 380 | 49 | 12.9% | +2.1 pts | | **Blended (store-wide)** | **8,140** | **664** | **8.2%** | **+1.3 pts** | The card reads a per-product split. The blended 8.2 percent looks borderline, but the alert at `>8% on any product` is tripped twice: Mypack Collect at 9.0 percent and Nordic export at 12.9 percent. Five things to notice: 1. **The split is the whole point.** Bedriftspakke (B2B) at 2.9 percent and home delivery at 6.0 percent are healthy and pull the blend down. Reading only the store-wide 8.2 percent would let you miss that two specific services are the problem. The per-product alert is what surfaces them. 2. **Mypack Collect at 9.0 percent and rising is a delivery-experience signal.** Pickup-point parcels return more when customers leave them uncollected, collect late, or find the pickup point inconvenient and reorder elsewhere. A returns spike on Mypack often shadows a pickup-expiry problem; check [Mypack Pickup Expiry Rate](/nerve-centre/kpi-cards/bring/mypack-pickup-expiry-rate). Some of those 487 "returns" may actually be uncollected parcels returned to sender, not customer-initiated returns. 3. **Nordic export at 12.9 percent is a different cause.** Cross-border returns spike when transit is slow (the customer changed their mind before it arrived) or when customs friction delayed clearance. Pair with [Nordic Export OTD (NO -> SE/DK/FI)](/nerve-centre/kpi-cards/bring/nordic-export-otd-no-sedkfi) and [NO Export Customs Clearance Rate](/nerve-centre/kpi-cards/bring/no-export-customs-clearance-rate): a slow export OTD drags the export return rate up. 4. **vsP is the early warning.** Mypack returns rose 1.8 points and export rose 2.1 points in 30 days. That is faster than a product-quality drift would move (quality issues build over months); a fast jump points at the delivery channel or a single bad batch, both of which are actionable now. 5. **This is revenue at risk you can attribute.** 664 returns at an average NOK 850 order value is roughly NOK 564,000 of reversed revenue in the window, plus return-shipping cost and restocking labour. Attributing it to product code tells you where to intervene: fix the Mypack notification flow, or move slow export lanes to a faster service. ## Sibling cards merchants should reference together Return rate by product code tells you where returns concentrate. Pair it with these to find the why: | Card | Why pair it with Return Rate by Product Code | What the combination tells you | | -------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Mypack Pickup Expiry Rate](/nerve-centre/kpi-cards/bring/mypack-pickup-expiry-rate) | Uncollected Mypack parcels return to sender. | A high Mypack return rate that tracks the expiry rate means the "returns" are really uncollected parcels, not customer rejections. Fix the notification flow, not the product. | | [Nordic Export OTD (NO -> SE/DK/FI)](/nerve-centre/kpi-cards/bring/nordic-export-otd-no-sedkfi) | Slow export transit drives buyer's-remorse returns. | If export OTD falls and export returns rise together, the customer changed their mind during a long wait. | | [NO Export Customs Clearance Rate](/nerve-centre/kpi-cards/bring/no-export-customs-clearance-rate) | Customs delays stall export parcels. | A clearance dip that precedes an export return spike points at border friction, not the goods. | | [Returned to Sender](/nerve-centre/kpi-cards/bring/returned-to-sender) | The RTS leg of the return picture. | Separates customer-initiated returns from carrier-driven RTS; the two need different fixes. | | [Exception Rate](/nerve-centre/kpi-cards/bring/exception-rate) | Delivery exceptions correlate with returns. | A product code with both a high exception rate and a high return rate has a delivery-experience problem. | | [On-Time Delivery Rate](/nerve-centre/kpi-cards/bring/on-time-delivery-rate) | Late delivery drives returns. | Per-product OTD against per-product return rate isolates which service's delays cost you the most reversed revenue. | | Cross-connector: [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) | The store-wide refund view. | The Bring per-product split explains a chunk of the blended refund rate; reconcile the two to size the carrier-attributable portion. | | Cross-connector: [`shopify.return_rate`](/nerve-centre/kpi-cards/shopify/return-rate) | The store-side return record. | The store sees every return; this card attributes them to the Bring service that carried the order. | ## Reconciling against the source **Where to look in Bring's own tooling:** [Bring Mybring](https://www.mybring.com/) → **Shipments → Shipment list**, filtered to Bring Retur (return) products, gives the inbound return consignments and the product code of the matching outbound parcel. **Reports → Booking history** lets you total outbound bookings per product code for the denominator. Bring does not compute a return rate of its own, because the return decision is the customer's and is recorded in your store; Mybring only shows the consignments it carried. The numerator (which orders were returned) is most authoritative in your store admin (Shopify Returns, BigCommerce RMA, Adobe credit memos); the product-code attribution is most authoritative in Mybring. The closest like-for-like check is: export the Mybring booking history for the period grouped by product code (denominator), then count inbound Bring Retur consignments per matching outbound code (carrier-side numerator), and compare against the store's own return count. **Why our number may legitimately differ from a manual reconciliation:** | Reason | Direction | Why | | ------------------------------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Carrier-side vs store-side returns** | Either | Some customers return without a Bring Retur label (drop at a store, third-party returns portal). Those appear in the store record but not in Mybring. The card uses the store return record as the numerator, so it can read higher than a Mybring-only count. | | **Uncollected Mypack counted as RTS, not return** | Mypack lower or higher | An uncollected Mypack parcel returns to sender via Bring's RTS flow. Depending on how your store records it (refund vs RTS), it may or may not be counted here. Reconcile against [Returned to Sender](/nerve-centre/kpi-cards/bring/returned-to-sender) to avoid double-counting. | | **Denominator cohort timing** | Recent days lower | Returns lag the sale. The most recent 7 to 10 days of the window have not had time to mature, so the absolute rate for those days reads low and rises as returns arrive. The vsP comparison is the stable signal. | | **Tracking-event ingestion lag** | Ours can lag | Inbound return scans arrive via the Bring Tracking API within minutes to a few hours of the physical event; a return booked this morning may not yet show in our index. | | **Carrier-local timestamps** | Boundary days off | Bring stamps scans in Norwegian local time. Returns near a window boundary can land in a different 30-day period than a raw Mybring timestamp read would suggest. | **Cross-connector reconciliation:** | Card | Expected relationship | Causes of legitimate divergence | | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | [`shopify.return_rate`](/nerve-centre/kpi-cards/shopify/return-rate) | The store sees all returns; this card splits the Bring-carried subset by product code. | Returns via non-Bring channels, store-credit-only returns, partial returns counted differently. | | [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) | Refunds overlap returns but are not identical. | A refund without a physical return (goodwill, damaged-in-transit write-off) inflates refund rate above return rate. | ***
Documentation cross-reference (for agencies running multiple carriers) Return-rate-by-service metrics exist with conceptually similar definitions across other carriers. These are not parallel measurements of the same orders. * [`postnord.return-rate-by-service`](/nerve-centre/kpi-cards/postnord/return-rate-by-service) (Nordic carrier peer) * [`shopify.return_rate`](/nerve-centre/kpi-cards/shopify/return-rate) (store-side return record)
## Known limitations / merchant FAQs **Why split by Bring product code instead of by product I sell?** Because the question this card answers is "does the delivery service affect returns?", not "which SKU comes back?". A high return rate on Mypack Collect across many SKUs points at the pickup-point experience; a high rate on one SKU across all services points at the goods. Use this card for the service question and your store's per-SKU return report for the goods question. **My Mypack return rate is high but my customers say they did not return anything. What is happening?** Those are almost certainly uncollected parcels returned to sender, not customer-initiated returns. A Mypack parcel that sits at the pickup point past its hold window is sent back, and if your store records that as a refund it lands here. Check [Mypack Pickup Expiry Rate](/nerve-centre/kpi-cards/bring/mypack-pickup-expiry-rate) and [Returned to Sender](/nerve-centre/kpi-cards/bring/returned-to-sender); the fix is the pickup-notification flow, not your returns policy. **Why is my export return rate always higher than domestic?** Two structural reasons. Cross-border transit is slower, so more customers cool off and return before the parcel even arrives, and customs friction can delay or damage the experience. A slow [Nordic Export OTD (NO -> SE/DK/FI)](/nerve-centre/kpi-cards/bring/nordic-export-otd-no-sedkfi) and a falling [NO Export Customs Clearance Rate](/nerve-centre/kpi-cards/bring/no-export-customs-clearance-rate) both pull export returns up. **The alert fired on one product but my blended rate is fine. Should I worry?** Yes, that is exactly what the per-product alert is for. A blended average can sit under 8 percent while one service is well above it; the healthy services hide the sick one. Act on the flagged code, not the blend. **Does a partial return count as a full return here?** The order is counted once as returned if any part of it comes back or is refunded. The card works at the order level for attribution to a single Bring product code. For line-item return depth, use your store's return analytics. **Why does the most recent week read artificially low?** Returns lag the sale by days to weeks, so orders shipped in the last 7 to 10 days have not had time to come back. Their cohort is still maturing. Read the vsP trend, not the raw rate for the most recent days, when judging whether returns are rising. **A return came in without a Bring Retur label. Is it counted?** If your store records the return or refund, yes, it is in the numerator. The card attributes it to the Bring product code of the original outbound parcel. Returns via non-Bring channels (in-store drop, third-party portal) still count against the outbound Bring service that delivered the order, which is intentional: it measures the service's contribution to returns even when the return leg used a different route. *** ### Tracked live in Vortex IQ Nerve Centre *Return Rate by Bring Product Code* is one of hundreds of KPI pulses Vortex IQ tracks across Bring and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.