Multi-currency i lokalizacija web shopa za više tržišta

Web shop koji prodaje na više tržišta treba da razlikuje tri stvari: valutu u kojoj kupac vidi cenu, jezik i lokalne poruke koje čita, kao i stvarne poslovne uslove porudžbine. Promena oznake EUR u RSD ili USD nije dovoljna ako checkout, dostava, porez, refundacija i potvrda porudžbine ostanu podešeni samo za matično tržište.

Dobro rešenje za web shop u više valuta zato se projektuje po tržištima, a ne samo po jezicima. Za svako tržište unapred se definišu dostupni proizvodi, cenovnik, valuta naplate, poreska pravila, metode plaćanja, zone dostave i način indeksiranja lokalnih stranica. Tek tada lokalizacija postaje kontrolisan sistem, a ne skup ručnih izmena u administraciji.

Ukoliko je potrebno da se ova logika ugradi u novi ili postojeći ecommerce sistem, ona treba da bude deo šireg obuhvata izrade web shopa, ali kao jasno izdvojen zahtev za međunarodnu prodaju. Komercijalna platforma može biti ista za sva tržišta, dok se pravila prikaza i kupovine razlikuju po zemlji, jeziku ili regionu.

Šta zapravo znači multi-currency web shop

Multi-currency funkcionalnost omogućava da kupac vidi i, u zavisnosti od podešavanja, plati proizvod u valuti koja odgovara njegovom tržištu. To ne znači nužno da svaka valuta ima potpuno nezavisan katalog. U praksi se najčešće koristi zajednički katalog sa tržišno specifičnim pravilima.

• Prikazna valuta određuje kako je cena predstavljena kupcu.
• Valuta naplate određuje u kojoj valuti payment gateway zaista autorizuje transakciju.
• Osnovna valuta služi za interno vođenje cena, izveštavanje ili računovodstvo.
• Valuta refundacije mora biti usklađena sa pravilima procesora plaćanja i originalnom transakcijom.

Ove valute mogu biti iste, ali ne moraju. Ako se cena samo preračunava po dnevnom kursu, prikaz može da se menja dok osnovna cena ostaje ista. Ako se za svako tržište održava poseban cenovnik, cena može biti stabilna u lokalnoj valuti, ali zahteva dodatno upravljanje.

Automatski kurs ili lokalni cenovnik?

To je jedna od najvažnijih odluka u projektu. Automatska konverzija je jednostavnija za početak: sistem polazi od osnovne cene i primenjuje kurs. Međutim, tako dobijena cena često ima nepraktične decimale, menja se kada se kurs osveži i ne mora da odgovara lokalnom pozicioniranju proizvoda.

Lokalni cenovnik daje veću kontrolu. Prodajna cena za određeno tržište može se ručno definisati, zaokružiti i prilagoditi lokalnoj ponudi, bez menjanja osnovne cene. Cena održavanja je veća jer se izmene moraju pratiti kroz više tržišta.

Pre odluke treba proveriti da li cena uključuje porez, kako se zaokružuje iznos, kada se kurs osvežava i šta se dešava sa već započetom korpom. Nije dobro da kupac doda proizvod u korpu u jednoj valuti, a da checkout neočekivano prikaže drugu cenu bez objašnjenja.

Lokalizacija je šira od prevoda

Prevod menija i opisa proizvoda jeste deo lokalizacije, ali nije njen završetak. Kupac na novom tržištu očekuje da razume sve elemente koji utiču na odluku i obavezu kupovine.

Elementi koje treba lokalizovati

• naziv, opis, varijante i dostupnost proizvoda;
• format cene, decimalni separator i pozicija oznake valute;
• poruke o porezu, dostavi, rokovima i carinskim obavezama;
• forme za adresu, poštanski broj i telefon;
• metode plaćanja koje su stvarno dostupne kupcima u regionu;
• e-mail potvrde, statusi porudžbine, refundacije i korisnička podrška;
• pravni dokumenti, uslovi kupovine i informacije o povraćaju.

Posebnu pažnju treba obratiti na adrese. Polja koja odgovaraju Srbiji nisu univerzalna: neka tržišta koriste drugačiji raspored administrativnih jedinica, različite formate poštanskog broja ili posebna pravila za telefonske brojeve. Ako checkout traži podatke koji nisu prirodni lokalnom kupcu, greška se može pojaviti tek na poslednjem koraku.

Kako povezati tržište, valutu i checkout

Najsigurniji pristup je da se definiše matrica tržišta pre implementacije. Tržište može biti država, grupa država ili poslovni region, ali mora imati jasna pravila. Primer matrice može izgledati ovako:

Tabela nije poreski savet niti konačna tehnička specifikacija. Njena svrha je da pokaže gde nastaju zavisnosti. Na primer, izbor GBP ne rešava automatski dostavu u Ujedinjeno Kraljevstvo, niti prevod na engleski znači da je checkout spreman za sve zemlje u kojima se engleski koristi.

Pre ulaska u razvoj treba definisati i ponašanje sistema kada lokacija korisnika nije poznata. Detekcija prema IP adresi može biti samo pomoćni signal, jer korisnik može putovati, koristiti VPN ili želeti da naruči na drugu adresu. Bolji model je da sistem predloži tržište, ali da korisnik može jasno da ga promeni. Izabrano tržište treba da bude vidljivo u zaglavlju ili drugom lako dostupnom delu interfejsa.

Plaćanje, refundacija i porudžbine u više valuta

Valuta prikaza i valuta transakcije moraju biti testirane odvojeno. Neki payment sistemi podržavaju više valuta, ali dostupnost zavisi od naloga trgovca, zemlje poslovanja, metode plaćanja i načina integracije. Zbog toga se ne treba osloniti na pretpostavku da će promena valute u frontend-u automatski promeniti valutu naplate.

Za svaku porudžbinu treba sačuvati najmanje:

• tržište i jezik u trenutku kupovine;
• valutu i iznos svake stavke;
• primenjeni kurs ili identifikator cenovnika;
• porez, trošak dostave, popust i konačan iznos;
• status payment autorizacije i refundacije.

Ovo je važno kada se kurs promeni nakon kupovine. Refundacija se ne sme računati kao nova konverzija bez provere pravila procesora, jer kupac očekuje da se povraćaj odnosi na originalnu transakciju. Statusi porudžbine takođe treba da budu precizni: plaćeno, delimično refundirano, otkazano i u obradi nisu ista stanja.

Za detaljniji model statusa, prelaza i refundacije korisno je pogledati vodič kako modelovati refund workflow i statuse porudžbine. Međunarodni shop samo dodaje valutu i tržište u već postojeći problem konzistentnosti podataka.

SEO struktura za više jezika i tržišta

SEO lokalizacija zahteva odluku o tome da li su tržišta predstavljena različitim URL-ovima, poddirektorijumima, poddomenima ili odvojenim domenima. Ne postoji jedna struktura koja je najbolja za svaki katalog. Važno je da izabrani model bude dosledan i da svaka lokalna verzija ima jasnu vezu sa drugim verzijama.

Za jezičke varijante treba pravilno koristiti hreflang oznake, canonical pravila i interne linkove. Valuta sama po sebi ne mora da opravda novu indeksiranu URL verziju. Ako se isti sadržaj otvara pod velikim brojem kombinacija filtera, jezika i valuta, nastaju duplikati i slabija kontrola crawl budžeta.

Prilikom planiranja proverite:

• da li svako ciljano tržište ima indeksabilnu i stabilnu URL verziju;
• da li naslov, meta opis, glavni sadržaj i strukturirani podaci odgovaraju jeziku i ponudi;
• da li canonical ne pokazuje nenamerno na matično tržište;
• da li hreflang veze postoje u oba smera i koriste ispravne jezičke/regionalne kodove;
• da li se cena i dostupnost u rezultatima pretrage slažu sa stranicom proizvoda;
• da li geo-redirect korisniku i pretraživaču ne blokira pristup drugim verzijama.

Ako se međunarodna verzija uvodi tokom prelaska na novu platformu, SEO plan treba povezati sa tehničkom migracijom. U tom slučaju je koristan vodič za migraciju web shopa, kataloga, porudžbina i SEO signala.

Faceted navigation i lokalne kategorije

Više valuta često dolazi zajedno sa većim brojem filtera, kategorija i tržišnih varijanti. Problem nastaje kada svaka kombinacija valute, jezika i filtera dobije indeksabilan URL bez jasne SEO svrhe. Tada se katalog može tehnički otvoriti, ali postaje težak za održavanje i kontrolu.

Treba odvojiti filtere koji su korisni kupcu od URL varijanti koje treba indeksirati. Na primer, lokalna kategorija može biti važna odredišna stranica, dok privremena kombinacija boje, veličine i valute najčešće nije. Pravila za canonical, robots direktive, interne linkove i sitemap treba definisati zajedno, a ne dodavati tek kada se pojave duplikati.

Za praktičan pregled ovog rizika pogledajte tekst o tome kako izbeći UX i SEO probleme kod filtera i faceted navigation.

Operativni proces: ko održava lokalizovane podatke?

Tehnička implementacija nije završena kada se pojavi birač valute. Potrebno je odrediti vlasnika svakog podatka i učestalost provere. To posebno važi za cenovnike, kurseve, poreze, dostavu i prevode.

1. Definišite tržišta. Napišite koje zemlje pripadaju kom tržištu i da li dele jezik, valutu i dostavnu zonu.
2. Napravite katalog pravila. Odredite dostupnost proizvoda, lokalne cene, poreze, minimalne iznose i ograničenja.
3. Uskladite checkout. Testirajte adresu, plaćanje, obračun dostave, potvrdu i refundaciju za svako prioritetno tržište.
4. Postavite SEO model. Izaberite URL strukturu, prevode, canonical i hreflang pravila pre masovnog objavljivanja stranica.
5. Uvedite kontrolu promena. Zabeležite ko menja cenu ili kurs, kada je promena stupila na snagu i kako se odražava na postojeće korpe.

Ako se sadržaj, katalog ili poslovna pravila menjaju u više sistema, treba definisati izvor istine. U suprotnom se može desiti da frontend prikazuje jednu cenu, ERP drugu, a e-mail potvrde treću. Za veći sistem korisno je predvideti logove promena, testno okruženje i kontrolnu listu za objavu.

Kontrolna lista pre objave

• Promena tržišta menja očekivani jezik, valutu i dostupne opcije.
• Cena na listingu, proizvodu, korpi, checkout-u i potvrdi je usklađena.
• Zaokruživanje i prikaz decimala rade prema dogovorenom pravilu.
• Testna naplata vraća tačnu valutu i iznos payment sistemu.
• Refundacija i otkazivanje čuvaju originalne iznose i statuse.
• Dostava, prag za besplatnu isporuku i porezi provereni su za svako tržište.
• Prevedeni su sistemski tekstovi, greške, e-mailovi i pravne stranice.
• Canonical, hreflang, sitemap i strukturirani podaci provereni su na lokalnim URL-ovima.
• Promena valute ne gubi sadržaj korpe niti menja porudžbinu koja je već poslata.

Najbolji sledeći korak nije izbor simbola valute, već kratak tehnički brief sa matricom tržišta, primerima proizvoda i realnim scenarijima kupovine. Kada su ta pravila jasna, lakše je proceniti da li postojeća platforma može da ih podrži, šta treba prilagoditi i koji deo treba uključiti u projekat izrade sajta ili specifično web shopa.