Nuo 2019 m. kuriu ir prižiūriu e-parduotuves Shopify, WooCommerce ir Wix platformose. Rašau temos kodą, custom sekcijas ir plugin'us, sutvarkau tai, ko standartiniai nustatymai nepadaro, ir paskui lieku prižiūrėti, kad viskas veiktų.
Kodas, e-komercijos logika, SEO, analitika ir automatizacijos – vienoje vietoje. Nereikia derinti trijų tiekėjų, kurie ima kaltinti vienas kitą, kai kažkas nustoja veikti.
Tikri atvejai iš klientų parduotuvių. Kiekvienas atrodė kaip viena problema, o priežastis buvo visai kitoje vietoje. Spustelėkite tą, kuris skamba pažįstamai.
Svetainės, prie kurių turiu prieigą ir prie kodo, ir prie administracinės dalies. Atskirame puslapyje kiekvieną matysite ir kompiuterio, ir telefono ekrane.
Vienas mygtukas produkto puslapyje paliečia visas keturias: temos kodą, krepšelio logiką, struktūrinius duomenis ir analitiką. Kai jos išbarstytos, pusė laiko nueina deriniams ir aiškinimuisi, kieno tai darbas.
Shopify Liquid sekcijos ir blokai, WordPress child temos, PHP hooks ir filtrai, custom mu-plugin'ai, Velo moduliai. Rašau tai, ko builder'is nepadaro.
Produktų ir variantų struktūra, metafields, kainodara, prenumeratos, checkout laukai, sąskaitos, pre-order, pristatymo taisyklės, mokėjimų gedimai.
Techninis auditas, struktūriniai duomenys, peradresavimai, hreflang, indeksavimo valdymas, meta masiniai atnaujinimai, matomumas DI atsakymuose.
Ataskaitos, lead'ų maršrutai, naujienlaiškiai, duomenų sujungimai tarp sistemų, DI pagrindu veikiantys darbo įrankiai su klientų kontekstu.
Pavyzdžiai, kurių nėra jokioje temoje ar plugin'e – juos reikėjo suprojektuoti ir parašyti.
Klientas turėjo kelis žmones, dalinančius nuorodas skirtinguose kanaluose, bet nežinojo, kieno nuoroda atnešė kurį užsakymą. Standartinė WooCommerce atribucija to nesuveda.
| Šaltinis | Žmogus | Užs. | € | |
|---|---|---|---|---|
| J. | 34 | 1 249 | PAID | |
| A. | 27 | 986 | PAID | |
| newsletter | – | 19 | 712 | FREE |
| organic | – | 12 | 431 | FREE |
Vienoje svetainėje JSON-LD turėjo tik pagrindinis puslapis, likę 91 – nulį. Platforma neleido pridėti struktūrinių duomenų globaliai, tik po vieną puslapį rankomis.
// site-wide, visos kalbos
{
"@context": "schema.org",
"@type": "Organization",
"address": { "@type": "PostalAddress" },
"geo": { "latitude": 55.664585 },
"sameAs": [ 6 profiliai ]
}
// tik /salonai
[ FurnitureStore × 4 ]
Anksčiau tai buvo radio mygtukai formos viduryje. Klientai jų nepastebėdavo ir įmonės rekvizitus rašydavo į užsakymo pastabas – kiekviena tokia sąskaita buvo taisoma ranka.
Beveik visi mano darbai prasideda ne nuo naujo dizaino, o nuo klausimo „kodėl tai neveikia“. Todėl eiliškumas visada toks pats.
Pirmiausia ieškau, kur iš tikrųjų lūžta. Dažnai priežastis būna visai kitoje vietoje, nei atrodė, ir brangaus perdarymo apskritai nereikia.
Renkuosi pakeitimą, kuris išsprendžia problemą ir atlaiko temos bei plugin'ų atnaujinimus. Perdarau iš naujo tik tada, kai kitaip tikrai neišeina.
Kiekvienas pakeitimas patikrinamas gyvame puslapyje, ne redaktoriaus peržiūroje. Struktūriniai duomenys – serverio HTML'e, peradresavimai – realiais užklausimais.
Palieku instrukciją ir sutvarkytą adminį, kad kasdienius dalykus klientas darytų pats. Manęs turi prireikti tik ten, kur iš tikrųjų reikia kodo.
Parašykite, kas negerai – arba ką norėtumėte, kad veiktų. Atsakau, ar tai išsprendžiama, kiek maždaug tai užtruks ir ar apskritai verta to daryti.
Siuzana
E-komercijos sistemos