Two couriers, one name: why you should key a tracking integration on number shape, not carrier name

When developing any system that deals with shipment tracking, such as an order page, a WISMO deflection flow, or a 3PL dashboard, there is a common mistake that often goes unnoticed during testing but manifests frequently in real-world scenarios: two different courier companies sharing the same name. For instance, CTT is the Portuguese postal service (ctt.pt), while CTT Express is a Spanish courier (cttexpress.com).

Although they operate under the same name, they are separate entities with distinct tracking systems. If your integration stores the carrier name as "CTT" and subsequently uses that string to create a tracking URL, you introduce an inherent uncertainty into your data model, leading to an unreliable outcome where customers may be directed to a page indicating that their parcel does not exist.

This issue is not rare; shippers frequently reuse initialisms and suffixes, leading to potential name collisions. For example, three-letter brand names, "Express" suffixes, and local operators might all use the same name for their services, causing confusion for both merchants and customers. Additionally, a generic word collision can be equally damaging for discovery purposes: 247Express, a real Vietnamese courier since 2005, shares the same string format as "247 tracking," leading users searching for the company or concept to end up on the same page.

To avoid these pitfalls, the recommended approach is to prioritize the tracking number over the carrier name. The tracking number is assigned by the carrier's own system and carries its unique format, making it a more reliable identifier. Therefore, it is advisable to resolve the carrier from the number pattern first, treating any stored carrier name as a mere hint rather than the definitive answer.

By doing so, when a merchant inputs "CTT" and the tracking number clearly follows the Spanish CTT Express pattern, the system can still route correctly, regardless of the carrier name provided. When constructing rules for pattern matching, it is crucial to anchor them both at the beginning and the end of the number, rather than relying on a simple length-based rule.

This approach prevents the accidental inclusion of numbers from other carriers, which could result in incorrect routing and data loss. Before implementing a new rule, thoroughly test it against your existing dataset to ensure that it does not inadvertently discard correctly formatted numbers from other carriers. If a new rule saves 30 unidentified numbers but misidentifies 120 correctly formatted ones, it represents a regression rather than an improvement.

Furthermore, avoid publishing a format for tracking numbers unless a single shape accounts for at least 60% of a carrier's numbers in your sample. Doing so ensures that only the most common and representative formats are shared, preventing confusion for users who may rely on these formats when searching for or verifying tracking numbers.

Lastly, never use a real tracking number as an example in your documentation or user interface copy. Such examples identify actual shipments and locations, making them sensitive information that should never be exposed publicly. Instead, provide the format of the tracking number when it applies to at least 60% of a carrier's numbers in your sample, and avoid providing any specific examples when the data is too varied.

By adhering to these guidelines, you can ensure that your shipment tracking integration is robust, reliable, and user-friendly, minimizing the risks associated with name collisions and format ambiguities.