Triathlon events have three separate starting lists: swim numbers, bike numbers (often on the frame), and run numbers. Some athletes use different numbers for each discipline. Matching photos to participants without losing data is a nightmare.
Mismatched photos get filed under the wrong athlete. Participants can't find their images. Sales drop 40-60% when gallery organization is confusing or incomplete.
CSV integration in triathlon is the process of matching AI-detected race numbers against participant databases that contain entries for swim, bike, and run disciplines separately — and sometimes timing chip numbers that don't align with visible race numbers.
Triathlon is a three-discipline event where the same participant wears different race numbers in each leg (swim cap, bike frame, chest bib on run). Professional photo services need to deliver organized galleries that participants can browse by discipline and find all their photos across the entire event. Without accurate CSV matching, you're either delivering unorganized galleries or manually organizing thousands of photos by hand.
In specifically:
In an Ironman event with 2,000 participants, you have: 2,000 swim cap numbers, 2,000 bike frame numbers, 2,000 run bib numbers. Late entries may have placeholders in the swim list but confirmed numbers in the bike/run. Some athletes drop out after swim (DNS = Did Not Start bike). Some finish swim and bike but DNF on the run. Body marking numbers (painted on arms) are sometimes used as a backup ID in the swim leg but may not match the official entry number. Your CSV workflow must handle all these variations.
Athlete's swim cap number is 487, but their bike frame number is 512, and their run bib is 512. All three numbers visible in different photos.
very common✗ Basic CSV matching links 487 and 512 as two different athletes. Photos get filed under two different participant profiles. Athlete sees their swim photo under 487 and run photo under 512 — looks like they're two people.
Event published two starting lists: preliminary (500 registered) with 300 numbers confirmed, and race-day final (547 confirmed) with 47 late entries added at numbers 501-547.
very common✗ If your CSV only has the preliminary list, photos of the 47 late-entry athletes won't match any participant record. You have to manually add them post-race or leave those photos untagged.
Timing chip database shows athlete #247 completed the swim at 09:14, but there is no entry under number 247 in the published race list. The athlete is actually listed under their body marking number (painted number, sometimes different from bib).
common✗ You can match swim photos by body marking number from your CSV, but the timing system uses chip data that references a different numbering scheme. Two data sources, two different number systems — no way to reconcile without manual lookup.
Athlete DNF'd (Did Not Finish) after the bike leg. Their bike frame number appears in 200+ photos from the bike leg, but they never appear on the run course. CSV has them registered with a run bib number they never wore.
occasional✗ Photos are tagged with bike number, but when you try to link to the CSV entry (which has run number), the match fails. Photos exist but can't be associated with a complete participant record without manual intervention.
Three separate CSVs, one per discipline
⚠ Requires manual lookup and spreadsheet work to reconcile swim number to bike number to run number. Impossible to track if a number appears in multiple CSVs for the same athlete.
Race organizer-provided master CSV with all three numbers per athlete
⚠ Only works if the race organizer provides a master list — many don't. Late entries and DNS/DNF athletes are handled inconsistently. If the race list has an error (athlete #123 listed twice, for example), your matching is broken.
Timing chip cross-reference (match by race time and discipline order)
⚠ Timing data only available for athletes who cross timing mats. In transition zones or between mats, you have photos but no timing reference. Doesn't solve the 'which number is which' problem across disciplines.
RaceTagger accepts a master CSV with participant number mappings (or separate CSVs for each discipline). As AI detects numbers in photos, it matches against the CSV using a fuzzy-match algorithm that handles late entries, DNS/DNF status, and discipline-specific number variations. For photos with ambiguous numbers (low-confidence detections), the system cross-references timestamp metadata with timing data if available to resolve the athlete identity.
Key advantage
Unified matching across three separate numbering schemes in one workflow. Instead of three manual reconciliation steps, you upload one (or three coordinated) CSV file(s) and the system handles the complexity. Late entries and DNS/DNF athletes are handled automatically as long as they're in the CSV.
96-98% — all three numbers clear and visible, master CSV up-to-date with late entries
Good conditions
91-95% — one number partially obscured, some late entries missing from CSV, DNF athletes present
Challenging
82-88% with confidence flags — multiple number systems in use, timing data unavailable, outdated CSV
Worst case
Before the race, collect three CSVs from race organizers: swim-to-athlete mapping, bike-to-athlete mapping, run-to-athlete mapping. If available, request a master CSV that maps all three to a single participant ID. Import into RaceTagger. As photos are processed, the system automatically creates athlete profiles and links photos across disciplines. Post-race, add the final DNS/DNF list from timing data. Regenerate matches. Output: master photo gallery organized by athlete (all three disciplines visible under each athlete's profile).
| Metric | Manual | Basic OCR | AI Vision (RaceTagger) |
|---|---|---|---|
| Processing time (2,000 athletes × 3 disciplines) | 6-10 hours (spreadsheet reconciliation + hand-tagging edge cases) | 45 minutes (but multiple CSVs require separate passes) | ~90 minutes (unified multi-CSV matching in one pass) |
| Handling late entries after registration closes | Manual lookup and re-tagging required | Requires re-processing with updated CSV | Automatic: update CSV, re-process, late entries retroactively matched |
| DNS/DNF athlete tracking | Spreadsheet notes + visual inspection | Limited — depends on number visibility in photos | Automatic: CSV status imported, photos tagged but marked as DNF/DNS in metadata |
| Multi-discipline number reconciliation | Manual lookup of swim→bike→run per athlete, 30-60 seconds per athlete | Not handled — requires separate CSVs | Unified matching: all three disciplines linked to single athlete profile |
| Cost per event | €100-200 (labor hours) | €20-40 (compute) | €50-80 (tokens + processing) |
Get the master CSV from race organizers BEFORE race day, even if it has TBD entries
A preliminary CSV with 'TBD' or placeholder numbers is better than scrambling post-race. You can update it as late entries confirm. The critical part is having the baseline mapping of swim → athlete, bike → athlete, run → athlete as early as possible.
Request both chip/timing numbers AND visible race numbers in the CSV — they're often different
Many triathlons have timing chips that reference a chip ID, and visible race numbers that reference bib/frame ID. Both should be in your CSV. If organizers only provide one, ask for a separate mapping document.
Shoot body marking numbers in the swim leg as a backup ID when swim cap numbers are unclear
Swim caps are hard to read from a distance (numbers are small and curved). Many athletes have body marking numbers painted on their arms. Capture both in your photos and your CSV. When cap numbers are ambiguous, body marking serves as confirmation.
Create a 'discipline tracker' column in your workflow to flag which discipline(s) each athlete appears in
Track which athletes completed swim (marked ✓), bike (marked ✓), run (marked ✓). After you've processed all photos, this shows you immediately that athlete #247 DNF'd the run (photos exist for swim+bike but not run). It also helps you validate that your CSV and photo gallery match reality.
For late entries added post-registration, get an updated CSV within 24 hours of race start and re-process photos
If 50 last-minute entries arrive the night before the race, their numbers likely won't be in your original CSV. Ask the race director for an updated list. Re-import and re-process photos — RaceTagger will pick up the new entries in a second pass.
Multi-discipline CSV integration. Upload three starting lists, process all photos once. Participants find all their images in one place.
Try it with your event →What if the swim cap number is different from the bike frame number? Does RaceTagger get confused?
No. If your CSV maps all three numbers to a single athlete ID (swim #487 → athlete 'John Doe', bike #512 → athlete 'John Doe', run #512 → athlete 'John Doe'), then RaceTagger links all photos to the same person across all disciplines. The AI doesn't care that the numbers are different — it matches to the athlete, not the number.
Can I use separate CSVs for swim, bike, and run instead of one master CSV?
Yes. RaceTagger accepts multiple CSVs and will cross-reference them by athlete name or ID. You'll need a column that identifies which athlete appears in which discipline (e.g., a participant ID). Upload all three CSVs in one import, and the system handles the reconciliation.
What happens to athletes who DNF or DNS (did not start/finish)?
If the CSV includes a 'status' column marking DNS/DNF athletes, RaceTagger imports that status. Photos of athletes who DNF'd the run will still be tagged with their number, but the athlete profile will show 'DNF' status. This helps you organize galleries correctly without losing photos.
If late entries are added after I've already processed photos, do I have to re-process everything?
You only need to re-process the new/updated portion of the CSV. RaceTagger will retroactively match any existing photos of the new athletes. So if 20 last-minute entries arrive and you re-import the updated CSV, any photos of those 20 athletes that you already processed will automatically get linked to their profiles.