Navnekonventioner til produktbilleder forbi 100.000 assets

De fleste studier vælger en navnekonvention en tilfældig tirsdag, skriver den på en wiki-side og går videre. Den holder de første ti tusind assets. Så tilføjer kunden en farve, retoucheren gemmer hurtigt et _v2-final-FINAL, nogen uploader Front.tif ved siden af front.TIF, og dagen før launch begynder storefronten at give 404 på et hero-shot.

Forbi 100.000 assets er en ad-hoc-navngivning ikke en lille irritation. Det er en driftsrisiko, der vælter PIM-joins, S3-listinger og næste migration. Denne artikel er den konvention, vi anbefaler de studier, vi auditerer - hvilke felter hører til i et filnavn, i hvilken rækkefølge, og hvordan I lander en omdøbning uden at vælte storefronten.

Hovedpointerne

En ad-hoc-konvention holder til ca. 10.000–20.000 assets. Derefter hober kollisioner, sortering og case-bugs sig op.
En holdbar navnekonvention til produktbilleder bærer fem felter: SKU, variant, vinkel, version, locale. En størrelses-token tilføjes nogle gange til ældre systemer, der læser på filnavnet.
Tokenrækkefølge er ikke ligegyldig. Sortér fra venstre mod højre efter det felt, der grupperer assets rigtigst i en flad listing.
Bindestreger slår underscore slår punktum. Hold jer til lowercase, ASCII og URL-sikre tegn. Sæt et praktisk længdeloft på 100 tegn, selvom filsystemet tillader mere.
Versionering hører hjemme i DAM'en, ikke i filnavnet - bortset fra to snævre undtagelser.
Omdøbninger er for evigt. Lever dem sammen med redirect-maps og PIM-joins i samme release.

Hvorfor ad-hoc-navngivning dør forbi 100.000 assets

Der dukker fire fejlmønstre op stort set samtidig - og de hober sig oven på hinanden.

Kollisioner. To fotografer skyder den samme SKU på forskellige dage og gemmer begge AB1234.tif. Den anden write enten overskriver den første lydløst eller fejler - afhængigt af storage. Begge dele er en dårlig dag.

Sortering. En flad S3-listing på 100.000 keys sorteres leksikografisk. Hvis version-token står yderst til venstre (v3-AB1234-RED-FRONT.tif), klumper alle versioner af alle assets sammen, og listingen er ubrugelig til stikprøver. SKU yderst til venstre løser det.

Søgning og joins. PIM og ERP joiner på substrenge af filnavne. De studier, der placerer SKU'en i position 3 i stedet for position 1, brænder udviklertimer på regex-baserede joins i flere år.

Case og Unicode. Windows er case-insensitiv. Linux og de fleste object stores er case-sensitive. URL'er er case-sensitive. Et studie, der blander Front, FRONT og front, ender før eller siden med at servere en 404 i produktion.

Library of Congress' vejledning om filnavne i digital bevaring rammer det samme problem mere nøgternt: filnavne skal være læsbare for mennesker, parserbare for maskiner og stabile på tværs af systemmigreringer. NIST's vejledning om filorganisering til forskningsdata lander samme sted. Ingen af dem er skrevet til e-handel, men begge gælder.

De fem felter, der altid hører til

Et filnavn skal svare på fem spørgsmål i fem tokens. Alt andet hører til i metadata, ikke i filnavnet.

SKU - den produkt-id, PIM'et ejer. Det er join-nøglen. Den skal matche eksakt.
Variant - farve, materiale eller størrelse, når SKU'en ikke selv koder den. På beklædning er det typisk farve.
Vinkel - front, back, side, detail, on-model, flat-lay. Brug et kontrolleret ordforråd, ikke fri tekst.
Version - kun når versionering i filnavnet er uundgåelig (se nedenfor). Ellers udelad det.
Locale - kun når selve assetet er locale-specifikt (en label-ændring til et marked, en regulatorisk on-pack-variant). De fleste assets behøver det ikke.

En størrelses-token (-1024, -thumb, -2048x2048) tilføjes nogle gange, når et nedstrømssystem ikke kan bede DAM'en om renditions og i stedet læser filnavnet. Behandl det som en legacy-indrømmelse, ikke som en del af master-filnavnet.

Anatomien i en navnekonvention til produktbilleder med tokens for SKU, variant, vinkel, version og locale — Fem tokens, fra venstre mod højre i vigtighed. Størrelses-token er udelukkende en legacy-indrømmelse.

Tokenrækkefølge, separatorer og case

Sortér tokens fra venstre mod højre efter det felt, der grupperer en flad listing rigtigst. For de fleste studier er rækkefølgen:

<SKU>-<VARIANT>-<VINKEL>-<VERSION>.<ext>

Tre regler dækker resten:

Bindestreger mellem tokens - aldrig underscore eller punktum. Bindestreger overlever URL-encoding rent, læses fint i shells, og dobbeltklik markerer dem som ét ord i de fleste editorer. Underscore virker, men spiller dårligt sammen med Markdown-kursivering i dokumentation. Punktum inde i stammen forvirrer biblioteker, der stripper alt efter første punktum, når de udregner extension.
Lowercase ASCII kun. Ingen versaler, ingen accenter, ingen mellemrum, ingen tegnsætning ud over bindestreg. Det lyder restriktivt - indtil I har leveret en 404 på en URL, der virkede lokalt.
Længdebudget. POSIX-grænsen for et filnavn er 255 bytes. S3-keys må være op til 1.024 bytes. URL'er er praktisk talt loftet ved ca. 2.000 tegn i browserne. Intet af det er den reelle grænse. Den reelle grænse er, at mennesker ikke kan læse et filnavn på 180 tegn. Læg loftet på stammen ved 100 tegn, så har I luft til alt.

AB1234-RED-FRONT-v3.tif er 22 tegn. Der er ingen grund til at gå længere.

Versionering i filnavnet versus i DAM'en

Den hyppigste navne-katastrofe er versionering i filnavnet. _v2, _FINAL, _FINAL_v2, _brug-denne. Alle studier har været igennem det.

Hovedreglen er enkel: versionering hører hjemme i DAM'en, ikke i filnavnet. En DAM, der behandler versioner som et førstegangsklasses-objekt, lader det samme logiske asset have ti revisioner - den seneste serveres alle steder som standard, og hele historikken kan auditeres. Filnavnet ændrer sig ikke mellem revisioner. Storefront-URL'er går ikke i stykker.

Der er præcis to tilfælde, hvor versionering i filnavnet er acceptabel:

Assetet forlader DAM'en. Når et færdigt asset eksporteres til en partner, der ikke selv bruger DAM (et printbureau, en marketplace der modtager via FTP), giver en version i filnavnet modtageren en stabil reference. Brug en kort token: -v3, ikke -version-tre-endelig.
Nedstrømssystemet afviser in-place opdateringer. Nogle PIM'er cacher aggressivt på filnavnet. Hvis I ikke kan invalidere cachen, må I omdøbe for at invalidere. Det er en workaround, ikke et mønster. Pres leverandøren til at fikse det.

Uden for de to tilfælde: versionér i DAM'en. For en grundigere gennemgang af, hvordan I strukturerer det, se vores guide til en versionspolitik for assets.

Konkrete eksempler pr. kategori

Tre kategorier dækker det meste, et packshot-studie skyder. Token-specifikationen tilpasser sig hver enkelt.

Beklædning og accessories. Variant er farve. Vinkel-ordforrådet er front, back, side, detail, on-model, flat.

AB1234-RED-FRONT-v3.tif
AB1234-RED-ON-MODEL.tif
AB1234-NAVY-FLAT.tif

Kosmetik. Variant er nuance eller størrelse. Vinkel-ordforrådet er front, back, lifestyle, swatch, texture.

LIP-2208-ROSE-FRONT.tif
LIP-2208-ROSE-SWATCH.tif
SER-501-30ML-BACK.tif

Fodtøj. Variant er farve og nogle gange bredde. Vinkel-ordforrådet får tilføjet pair, sole, three-quarter.

SH-9912-BLACK-PAIR.tif
SH-9912-BLACK-SOLE.tif
SH-9912-BLACK-THREE-QUARTER.tif

Læg mærke til, hvad der ikke står i nogen af navnene: fotografens initialer, shoot-dato, retoucher, sæson, kanal. Det hører til i struktureret metadata, hvor det kan søges, filtreres og ændres uden at omdøbe en eneste fil.

Migration væk fra det nuværende kaos

De færreste studier kan starte forfra - I har en historik. En migration kører i tre faser, samme måde som skiftet fra fildrev til DAM gør.

Fase 1 - frys og før videre. Fra dag ét bruger alle nye assets den nye konvention. Gamle assets bliver liggende. Det stopper blødningen med det samme.

Fase 2 - omdøb det aktive sæt. De seneste 6–12 måneders løbende assets omdøbes til den nye konvention. Det er her, det kræver omhu. Lever omdøbningen sammen med:

En redirect-map for hver offentlig URL, der refererede til det gamle filnavn.
En PIM-opdatering, der bytter gamle filnavne ud med nye i samme release-vindue.
En storefront cache purge, så besøgende ikke ser cachede 404'ere.
En read-only fallback på det gamle navn i et defineret vindue - typisk 90 dage - så partnere på gamle links har tid til at opdatere.

Fase 3 - backfill af arkivet. Arkivet omdøbes i bidder, knyttet til konkrete projekter. En reshoot til forårskataloget er et naturligt tidspunkt at omdøbe sidste års forårsbilleder - ikke et selvstændigt spor.

Den største enkeltfejl er at behandle fase 2 som en filnavnsændring i stedet for en release. Omdøbninger er for evigt. Det er infrastrukturarbejde, ikke oprydning.

Sådan ser det rigtige ud - fem spørgsmål til tjek

Før I lægger en navnekonvention på wiki'en og i studio managerens onboarding, så kør den igennem disse:

Grupperer venstre token listingen, som teamet rent faktisk har brug for at scanne den?
Er hver token fra et kontrolleret ordforråd - ikke fri tekst?
Round-tripper konventionen gennem en URL, en Excel-celle og en Bash-shell uden escaping?
Er den samlede stamme under 100 tegn i et realistisk worst case?
Hvis et partnersystem forsvinder i morgen, kan PIM- og ERP-integrationen stadig joine på SKU-token alene?

Hvis et svar føles ubehageligt, er konventionen ikke klar. Fiks det før de næste 10.000 assets - ikke efter de næste 100.000.

Hvis I vil have et par friske øjne på den konvention, I har i dag - inklusive hvordan den ville overleve en migration ind i PixelAdmin - så tager vi en gennemgang på 45 minutter på jeres nuværende filnavne, PIM-joins og storefront-URL'er.