Cinque servizi di consegna in un unico plugin: SDEK, KIT, Business Lines, Russian Post, Boxberry

La scorsa settimana mi ha scritto il titolare di un negozio online di lubrificanti industriali. Un uomo vende oli, fluidi idraulici, antigelo: merci pesanti e ingombranti che devono essere consegnate in tutta la Russia. Ed ecco cosa ha detto: ha cinque plugin di consegna separati sul suo sito web. Uno per SDEK, uno per Boxberry, uno per Business Lines, un altro per Russian Post e l'ultimo per KIT. Ogni plugin costa da tre a diecimila rubli all'anno. Ognuno viene aggiornato secondo il proprio programma. Ognuno ha la propria interfaccia delle impostazioni. E così si siede e pensa: è davvero impossibile far funzionare tutto da un unico posto? In modo che l'acquirente alla cassa possa vedere tutte le opzioni di consegna contemporaneamente e possa selezionare un punto di ritiro sulla mappa, invece di dover cercare tra infiniti pulsanti di opzione?

L'ho ascoltato e ho capito che questa non era una situazione unica. Questo è un problema che quasi tutti i proprietari di negozi WooCommerce in Russia devono affrontare. E più grande è il negozio, più acuto è questo dolore. Perché cinque plugin non sono solo cinque abbonamenti. Questi sono cinque potenziali punti di fallimento. Cinque diversi team di sviluppo che potrebbero abbandonare il loro prodotto o rilasciare un aggiornamento che interrompe la compatibilità con l'ultima versione di WordPress. Si tratta di cinque diversi stili di visualizzazione alla cassa, che non sono coerenti tra loro e danno all'acquirente la sensazione che il sito sia assemblato da pezzi su nastro.

Quando abbiamo progettato il modulo di consegna per COS WP Woo, siamo partiti da un'idea semplice: un plug-in: tutti i corrieri. Non un aggregatore che ti addebita una commissione per ogni ordine. Non un involucro universale che si rompe ogni volta che cambia l'API della compagnia di trasporti. E un'integrazione diretta a tutti gli effetti con l'API di ciascun operatore, uniti da un'unica interfaccia software. Sembra semplice? In pratica questo significa mesi di lavoro, centinaia di ore di test e decine di sfumature di cui voglio parlare.

Ma non cominciamo dai dettagli tecnici, bensì da quelli economici. Perché alla fine al proprietario del negozio non interessa quanto abbiamo progettato bene l'architettura, ma quanti soldi risparmierà e quanti problemi scompariranno dalla sua vita quotidiana.

Aritmetica che parla da sola

Facciamo i conti. Plugin per SDEK: da cinquemila rubli all'anno per la versione normale con supporto per API v2. Boxberry: più o meno lo stesso, forse un po 'più economico, tre o quattromila. Linee di business: qui ci sono meno opzioni, i buoni plugin partono da seimila. Poste russe: altri da tre a cinquemila. KIT - Pochissimi lo fanno, ma quando lo fanno chiedono dai cinque ai settemila, perché il mercato è piccolo e non c'è quasi concorrenza. Totale: da quindici a cinquantamila rubli all'anno solo per i plugin di consegna. E questo non tiene conto del tempo che il tuo tecnico (o tu stesso) spendi per impostare il tutto, sincronizzarlo e mantenerlo funzionante.

Ma il denaro non è la cosa peggiore. La cosa peggiore sono i conflitti. Ricordo un caso in cui uno dei nostri clienti, dopo aver aggiornato WordPress alla 6.5, due plugin di consegna su cinque hanno smesso di funzionare. Si sono semplicemente fermati. Gli sviluppatori di uno hanno risposto in una settimana, del secondo in tre settimane. Per tutto questo tempo, il negozio ha lavorato con opzioni di consegna limitate, ha perso ordini e ha ricevuto recensioni negative. Perché l'acquirente non capirà perché la sua compagnia di trasporti preferita non è alla cassa, andrà semplicemente da un concorrente.

C'è un altro punto di cui poche persone parlano. Ogni plug-in di consegna aggiunge i propri script e stili alla pagina di pagamento. Uno collega un widget jQuery per una mappa, un altro collega il proprio componente React, il terzo collega qualcos'altro. Di conseguenza, la pagina di pagamento viene caricata in quattro-cinque secondi invece dei due richiesti e il tasso di conversione diminuisce. Esistono studi che dimostrano che ogni secondo in più di caricamento alla cassa riduce la conversione dal 7 al 10%. Moltiplicalo per la tua fattura media e il numero di ordini al mese: i numeri sono impressionanti.

Quando tutti i gestori funzionano con un plug-in, si tratta di un download di script, di una mappa, di una richiesta AJAX per il calcolo dei costi. Non cinque richieste a cinque API diverse, ma una richiesta al tuo server, che sul backend interroga in parallelo tutte le API necessarie e restituisce un risultato consolidato. La differenza di velocità è colossale.

Come abbiamo affrontato l'architettura: un'interfaccia - tutti gli operatori

Sapete cosa distingue un buon sistema ingegneristico da uno cattivo? Un buon sistema è progettato in modo che l'aggiunta di un nuovo elemento non rompa quelli esistenti. Quando abbiamo iniziato a progettare il modulo di consegna, la prima cosa che abbiamo fatto è stata definire un contratto comune per tutti i corrieri. Nella programmazione, questa è chiamata interfaccia e la nostra CarrierInterface descrive esattamente quattro cose che ogni corriere dovrebbe essere in grado di fare: fornire il proprio codice e nome, calcolare il costo della consegna, restituire un elenco di punti di ritiro e verificare se le chiavi API sono configurate.

Perché questo è importante per te come proprietario di un negozio? Perché questo significa che tutti gli operatori funzionano esattamente allo stesso modo dal punto di vista del sistema. Al momento del pagamento, l'acquirente vede una tabella uniforme, dove per ciascun corriere vengono indicati il ​​costo, i tempi di consegna e se la consegna è disponibile alla porta o al punto di ritiro. Non è necessario comprendere le diverse interfacce dei diversi plugin. Tutto sembra uno perché è uno.

Abbiamo implementato cinque corrieri: SDEK, KIT, Business Lines, Russian Post e Boxberry. Ognuna di esse è una classe separata che implementa un'interfaccia comune. CdekCarrier funziona con l'API SDEK versione 2.0, utilizza l'autorizzazione OAuth e supporta due tariffe: consegna al punto di emissione e consegna tramite corriere alla porta. KitCarrier si integra con l'API KIT Auto, particolarmente rilevante per il trasporto interurbano di merci pesanti e di grandi dimensioni. DellineCarrier collabora con Business Lines, una delle più grandi società di trasporti in Russia, indispensabile se si inviano pallet o merci di grandi dimensioni. PostRussiaCarrier si collega all'API Russian Post tramite otpravka-api.pochta.ru e calcola il costo per pacchi, pacchi, EMS e consegna tramite corriere. Infine, BoxberryCarrier funziona con l'API Boxberry, particolarmente apprezzata nel segmento dei pacchi di piccole e medie dimensioni.

È qui che voglio fermarmi e spiegare perché abbiamo scelto l'integrazione diretta dell'API anziché un aggregatore. Esistono sul mercato soluzioni come eShopLogistic, che fungono da intermediario tra il tuo negozio e le aziende di trasporto. L'idea è bellissima: colleghi un servizio e ottieni l'accesso a tutti gli operatori tramite un'unica API. Noi stessi abbiamo utilizzato questo approccio in uno dei progetti e abbiamo riscontrato una serie di problemi che ci hanno costretto a riconsiderare la nostra strategia.

Il primo e più ovvio problema è un ulteriore punto di errore. Quando è presente un altro servizio tra il tuo negozio e SDEK, qualsiasi guasto da parte di questo servizio significa che tutti i tuoi operatori smettono di funzionare contemporaneamente. L'abbiamo riscontrato due volte in sei mesi: l'aggregatore è rimasto fermo per diverse ore e l'intero checkout è rimasto paralizzato. Con l'integrazione diretta, se l'API SDEK non risponde, tutti gli altri operatori continuano a funzionare. L'acquirente semplicemente non vedrà le opzioni SDEK, ma potrà scegliere Boxberry o Business Lines.

Il secondo problema è la velocità. La richiesta tramite l'aggregatore avviene in questo modo: il tuo server → aggregatore → API dell'operatore → aggregatore → il tuo server. Si tratta di cento-duecento millisecondi in più per ogni richiesta, il che si traduce in un notevole ritardo al momento del pagamento. Con l'integrazione diretta, il tuo server accede direttamente all'API del corriere e la risposta arriva più velocemente.

Il terzo problema è la rilevanza dei dati. Gli aggregatori non sempre rilevano immediatamente le modifiche nell'API delle aziende di trasporto. Quando SDEK ha aggiornato le sue API alla versione 2.0, alcuni aggregatori hanno lavorato ancora per mesi sulla vecchia versione e hanno restituito dati imprecisi su costi e condizioni. Con l'integrazione diretta, lavori con la versione più recente dell'API e ottieni i calcoli più accurati.

Ad essere onesti, l'integrazione diretta ha uno svantaggio: è difficile da supportare. Quando ciascun operatore aggiorna la propria API, dobbiamo aggiornare la classe corrispondente nel nostro plugin. Ma proprio per questo motivo esiste un'unica CarrierInterface: i cambiamenti in un operatore non influiscono sugli altri. Possiamo aggiornare facilmente CdekCarrier senza toccare BoxberryCarrier e tutto continuerà a funzionare.

E se lo guardassimo da un'altra prospettiva? Immagina che domani appaia sul mercato una nuova compagnia di trasporti che offre tariffe eccellenti nella tua regione. Con la nostra architettura, l'aggiunta di un nuovo operatore equivale alla creazione di una nuova classe che implementa la stessa interfaccia. Nessuna modifica al codice esistente, nessun rischio di rompere nulla. Abbiamo creato una classe, l'abbiamo registrata nel sistema ed è già apparsa alla cassa accanto alle altre. Prova a raggiungere questo obiettivo con cinque plugin separati di diversi sviluppatori.

FIAS, indirizzi e perché la ricerca di stringhe è un percorso che non porta da nessuna parte

C'è un argomento su cui gli sviluppatori di plugin di consegna di solito tacciono timidamente. Questo è un problema di determinazione della città ricevente. Sembrerebbe che qui non ci sia nulla di complicato: l'acquirente è entrato in città, il sistema lo ha trasferito alla compagnia di trasporti e ha ricevuto un calcolo. Ma in pratica è tutto molto più divertente.

Prova a inserire "Chelyabinsk" in diverse API: tutto funzionerà correttamente. Adesso prova Nizhny Tagil. O "Naberezhnye Chelny". O "Rostov sul Don". Ogni compagnia di trasporti ha il proprio elenco di città, il proprio formato del nome e i propri codici. SDEK utilizza i propri codici di città interni. Boxberry - nostro. Business Line: i tuoi terminali. Russian Post opera in base ai codici postali. E ora stai scrivendo convertitori da un formato all'altro, gestendo le differenze di ortografia (con o senza trattino, in quale ordine appaiono le parole), e questo si trasforma in un incubo di supporto senza fine.

Abbiamo risolto radicalmente questo problema. Invece di abbinare stringhe di nomi di città tra diverse API, utilizziamo FIAS - Federal Information Address System. Questo è il classificatore di indirizzi ufficiale della Federazione Russa, dove a ciascuna località viene assegnato un identificatore univoco: GUID. Questo identificatore non dipende da come scrivi il nome della città: cirillico, latino, con o senza errori di battitura.

Nel nostro sistema, ogni classe di spedizione in WooCommerce è legata al codice FIAS della città di spedizione. Ciò significa che quando un prodotto viene inviato da un determinato magazzino, il sistema sa esattamente da quale città viene inviato, non tramite il nome della stringa, ma tramite un identificatore univoco nell'elenco federale. Per la città del destinatario, utilizziamo una combinazione di metodi: codice FIAS, se disponibile, o codice postale per Russian Post o codice città interno per i corrieri che forniscono un'API di ricerca città.

Mi chiedo da molto tempo perché altri sviluppatori non utilizzano questo approccio. La risposta, come al solito, è semplice: è più difficile da implementare. La ricerca di stringhe è una riga di codice. L'integrazione FIAS è una classe ShippingFias separata che aggiunge una colonna di codice FIAS alle impostazioni della classe di spedizione di WooCommerce, memorizza questi codici nei metadati della tassonomia e li fornisce durante il calcolo della spedizione. Ma il risultato vale lo sforzo: il calcolo funziona correttamente per qualsiasi città della Russia, senza errori dovuti alle differenze nell'ortografia dei nomi.

Ecco un esempio specifico tratto dalla nostra pratica. Uno dei clienti vendeva oli in tutta la Russia e si è trovato di fronte al fatto che durante l'invio alla città di Noyabrsk, il vecchio plugin SDEK non riusciva a trovare questa città, perché nella sua directory interna la città era registrata come "Noyabrsk (regione di Tyumen)", e l'acquirente ha inserito semplicemente "Noyabrsk". L'ordine è stato bloccato, il gestore ha chiamato il cliente, ha chiarito l'indirizzo e ha creato manualmente un'applicazione sul sito SDEK. Moltiplicate questo per venti o trenta casi simili al mese e capirete la portata del problema. Con FIAS questo problema semplicemente non esiste, perché Noyabrsk ha uno e un solo GUID nell'elenco federale e tutti i vettori ricevono esattamente quello.

C'è un altro aspetto dell'utilizzo degli indirizzi che vale la pena menzionare: il raggruppamento delle merci per magazzino di spedizione. Negli affari reali, soprattutto nel segmento B2B, le merci vengono spesso immagazzinate in magazzini diversi. Uno dei nostri clienti aveva oli Shell in un magazzino a Chelyabinsk, oli Lukoil in un magazzino a Nerson e fluidi idraulici in un magazzino di marketing in un'altra località. Ogni magazzino ha la propria classe di consegna in WooCommerce con un codice FIAS associato. Quando un acquirente aggiunge al carrello articoli provenienti da diversi magazzini, il nostro sistema li raggruppa automaticamente e calcola il costo di spedizione separatamente per ciascun gruppo. L'acquirente vede che la consegna costa così tanto per gli oli Shell e così tanto per gli oli Lukoil, e il costo totale è questo. Trasparente, comprensibile, senza sorprese nascoste.

Checkout di cui puoi essere orgoglioso: matrice di consegna e mappa dei punti di ritiro

Ora parliamo di ciò che vede l'acquirente. Perché puoi costruire l'architettura perfetta sul backend, ma se alla cassa tutto sembra un foglio di calcolo Excel del 1998, nessuno starà meglio.

Abbiamo creato una matrice di consegna: una tabella in cui l'acquirente vede tutte le opzioni disponibili da tutti i corrieri collegati. Per ciascuna opzione vengono visualizzati il ​​nome del corriere, la tipologia di consegna (al domicilio o al punto di ritiro), il costo e il tempo stimato. L'acquirente seleziona l'opzione appropriata con un clic. Se ha scelto la consegna presso il punto di ritiro, si apre una mappa con segnati i punti del corriere da lui scelto. Sulla mappa puoi trovare il punto di ritiro più vicino, visualizzarne l'indirizzo e gli orari di apertura.

Sai cosa mi ha sempre infastidito dei plugin di consegna esistenti? Mostrano le opzioni in sequenza: prima tutte le opzioni SDEK, poi tutte le opzioni Boxberry, quindi tutte le opzioni Russian Post. E l'acquirente stesso deve scorrere questa lista infinita, confrontando prezzi e condizioni. Tutto è chiaro nella nostra matrice: tutti i corrieri sono nelle vicinanze, confronta e scegli. Credo che questo influisca notevolmente sulla conversione, anche se non abbiamo ancora condotto test A/B accurati per questo particolare elemento. Ma la logica impone: quanto più facile è per una persona prendere una decisione, tanto più velocemente effettuerà un ordine.

Vale la pena menzionare separatamente l'implementazione tecnica della matrice al momento del pagamento. WooCommerce fornisce un meccanismo di metodi di spedizione standard e il nostro modulo registra un singolo metodo di spedizione con l'ID wpaic_shipping. Un metodo, non cinque separati. Ciò significa che tutti i corrieri funzionano con lo stesso metodo di spedizione WooCommerce, si integrano correttamente con le zone di spedizione WooCommerce e non sono in conflitto con altri metodi di spedizione che potresti utilizzare (ad esempio, ritiro all'esterno o spedizione gratuita per un determinato importo dell'ordine).

Il calcolo dei costi avviene in tempo reale tramite l'API di ciascun operatore. Quando l'acquirente inserisce il suo indirizzo al momento del pagamento, il nostro plugin invia i parametri dell'ordine (peso, dimensioni, valore dichiarato, città del destinatario) a ciascuna API connessa e riceve indietro il costo e i tempi di consegna. I risultati vengono memorizzati nella cache per dieci minuti (si tratta di un'impostazione configurabile) per evitare di sovraccaricare l'API con richieste ridondanti se un cliente aggiorna la pagina o modifica il numero di articoli nel carrello.

Qui voglio parlare di una sfumatura tecnica che può sembrare banale, ma in pratica ci è costata diversi giorni di debug. In WooCommerce, i dati della sessione sono stringhe. Quando ottieni il peso di un articolo da una sessione, ottieni la stringa "1.5" anziché il numero 1.5. E se passi questa stringa alla funzione round() in PHP 8.x senza convertirla esplicitamente in float, otterrai un errore. Sembra banale, ma immagina di avere cinque operatori e ognuno di essi riceve dati dalla sessione: se almeno uno sviluppatore si dimentica del casting del tipo, il calcolo dei costi verrà interrotto. Nel nostro codice, ogni valore numerico dei parametri viene esplicitamente convertito in float prima delle operazioni matematiche. Una sciocchezza? SÌ. Ma sono proprio queste piccole cose che compongono il lavoro stabile.

Ed ecco un altro punto che ritengo di fondamentale importanza. I calcoli di consegna vengono visualizzati tramite l'hook woocommerce_review_order_before_payment e non tramite before_order_review, come consigliano molte guide. Perché? Perché before_order_review non funziona correttamente con i temi WordPress a blocchi, che stanno diventando uno standard. Abbiamo passato molto tempo a capire perché la matrice di consegna semplicemente non appariva su uno dei nostri siti di prova con il tema Twenty Twenty-Five finché non abbiamo scoperto che l'hook before_order_review nei temi a blocchi veniva attivato prima che il modulo di pagamento fosse stato completamente renderizzato. Il passaggio a before_payment ha risolto il problema. Esistono dozzine di sfumature di questo tipo e sono ciò che distingue un plugin che “sembra funzionare” da un plugin che funziona in modo affidabile.

Tracciabilità: dalla creazione dell'ordine alla consegna del pacco

La consegna non riguarda solo il calcolo del costo e la scelta del corriere al momento del pagamento. Questo è anche ciò che accade dopo aver effettuato un ordine. L'acquirente vuole sapere dove si trova il suo pacco, quando arriverà e cosa fare se qualcosa va storto. È qui che inizia il caos per la maggior parte dei negozi WooCommerce.

Uno scenario tipico è questo: un manager inserisce una spedizione sul sito web della compagnia di trasporti, ottiene il numero di tracciabilità, lo copia, lo incolla nella nota dell'ordine in WooCommerce e forse - forse! — invia all'acquirente un'e-mail con questo numero. L'acquirente riceve una lettera, va sul sito web del corriere, inserisce il numero di traccia e controlla lo stato. Se il corriere è diverso, deve sapere su quale sito verificare. Se l'ordine contiene merci provenienti da più corrieri (ricordate il raggruppamento per magazzini?), l'acquirente deve tracciare diversi numeri di tracciabilità su diversi siti web.

Abbiamo integrato il tracciamento delle spedizioni direttamente nel sistema. Quando il gestore inserisce il numero di traccia nella scheda dell'ordine, l'acquirente lo vede nel suo account personale sul sito web del negozio. Non c'è bisogno di visitare siti di terzi, non c'è bisogno di ricordare quale corriere consegna quale parte dell'ordine. Tutto è in un unico posto: nome del corriere, numero di traccia, stato attuale. Quando lo stato della spedizione cambia, l'acquirente riceve una notifica via email.

Sento spesso la domanda: "Perché farlo in un plugin se l'acquirente può già controllare la traccia sul sito web del corriere?" La risposta è semplice: si tratta dell'esperienza del cliente. Un negozio in cui tutte le informazioni sono disponibili in un unico posto, nel tuo account personale, è percepito come più professionale e affidabile. L'acquirente non pensa "Ho ordinato su qualche sito web, ma è stato consegnato da SDEK". Pensa: "Ho ordinato da questo negozio e si sono assicurati che fosse facile per me monitorare la consegna". Sono le piccole cose che creano fedeltà.

Ora parliamo del lato venditore. Se hai un negozio online con decine di ordini al giorno, gestire la consegna diventa un lavoro ingrato. Tieni traccia di numeri, stati, notifiche: tutto questo deve essere controllato. Il nostro modulo di consegna si integra con il modulo 1C, che fa anche parte di COS WP Woo. Ciò significa che gli stati delle spedizioni possono essere sincronizzati con il tuo sistema contabile. Il manager in 1C vede che l'ordine è stato inviato, qual è il numero di traccia, qual è il corriere, qual è lo stato attuale. Non è necessario passare da un sistema all'altro: tutto è sincronizzato.

So che molte persone sono scettiche riguardo all'idea del "plug-in tutto in uno". E capisco questo scetticismo. Le soluzioni universali sono spesso inferiori a quelle specializzate in termini di elaborazione. Ma qui c’è una sfumatura importante: non creiamo un plugin per tutto. Stiamo realizzando un plug-in per l'ecosistema del negozio WooCommerce, in cui tutti i moduli lavorano insieme e scambiano dati. Il modulo di consegna conosce il modulo 1C. Il modulo 1C conosce il modulo B2B. Il modulo B2B conosce il modulo di notifiche e-mail. Questa non è una raccolta di funzioni disparate stipate in un unico file ZIP: è un sistema integrato, in cui ogni modulo migliora gli altri.

Russian Post è un corriere che si è sempre distinto

Voglio parlare separatamente di Russian Post, perché la sua integrazione è una storia a parte, piena di dolore e gioia allo stesso tempo. Russian Post è la più grande rete logistica del paese. Più di quarantaduemila filiali. Consegna in qualsiasi località, compresi villaggi e città, dove nessun corriere commerciale si recherà. Per molti negozi, Russian Post è l'unico modo per consegnare merci in regioni remote.

Allo stesso tempo, l'API Russian Post è, per usare un eufemismo, una cosa peculiare. Hanno due API: un calcolatore tariffario (pubblico, senza autorizzazione) e un'API di invio (con autorizzazione tramite token e login). Il calcolatore delle tariffe funziona in base al codice postale: passi l'indice di invio, l'indice di ricezione, il peso, il tipo di articolo e il valore dichiarato e ottieni il costo. Sembra semplice, ma il diavolo, come sempre, è nei dettagli.

Il tipo di invio è qualcosa che confonde la maggior parte degli sviluppatori. Pacco, pacco postale, EMS, consegna tramite corriere: ogni tipo ha il proprio codice, le proprie restrizioni su peso e dimensioni e il proprio tariffario. Il nostro PostRussiaCarrier determina automaticamente il tipo di spedizione ottimale in base al peso e al valore dichiarato dell'ordine. Se il pacco è leggero, viene calcolato come pacco postale (è più economico). Se è pesante, è come un pacco standard. Se l'acquirente desidera più velocemente, offre la consegna EMS o tramite corriere. L'acquirente vede tutte le opzioni disponibili con prezzi e termini e sceglie ciò che gli si addice.

La gestione degli errori è una storia diversa. L'API Russian Post può restituire un errore per un motivo del tutto non ovvio, ad esempio perché il codice postale si riferisce a un'unità militare o a un'entità territoriale chiusa. In questi casi, il nostro plugin non mostra all'acquirente un messaggio di errore crittografico, ma semplicemente non mostra le opzioni di Russian Post, lasciando disponibili altri corrieri. Sembra una cosa da poco, ma per l'acquirente c'è un'enorme differenza: tra "Errore nel calcolo della consegna, riprova più tardi" e un pagamento normalmente funzionante, in cui una delle opzioni semplicemente non è disponibile.

Ed è qui che inizia il divertimento dal punto di vista architettonico. Ricordi quando ho parlato della singola CarrierInterface? Ciascun corriere nel metodo calcola() restituisce un risultato standardizzato: stato di successo, prezzo, scadenza, testo dell'errore (se presente) e codice del corriere. Ciò significa che il sistema di elaborazione dei risultati è assolutamente lo stesso per tutti i vettori. Se SDEK ha restituito un errore, visualizziamo il resto. Se Russian Post ha restituito un errore, visualizzeremo il resto. Se tutti hanno restituito un risultato positivo, mostriamo la matrice completa. La logica è semplice e affidabile, perché non dipende dalle specificità di un particolare operatore.

SDEK e Boxberry sono due giganti che dovrebbero essere amici

SDEK e Boxberry sono forse i due operatori più popolari per i negozi online in Russia. SDEK dispone di un'enorme rete di punti di consegna: oltre quattromila in tutto il paese. Il Boxberry presenta i suoi vantaggi, soprattutto nel segmento delle piccole parcelle e nelle regioni in cui l'SDEK è scarsamente rappresentato. Molti negozi collegano entrambi i servizi per offrire all'acquirente la massima scelta.

SDEK è passato all'API v2.0, che utilizza l'autorizzazione OAuth. Ciò significa che per ottenere l'accesso all'API, è necessario prima ottenere un token di accesso scambiando client_id e client_secret con un token al portatore temporaneo. Il nostro CdekCarrier lo gestisce automaticamente: riceve il token, lo memorizza nella cache nei transitori di WordPress, lo aggiorna automaticamente quando scade. Per te come utente, questo significa che inserisci client_id e client_secret nelle impostazioni del plugin una volta e non ci penserai mai più.

La situazione con Boxberry è più semplice: hanno l'autorizzazione tramite un token, che viene passato come parametro di richiesta. Ma Boxberry ha le sue difficoltà nel definire una città. Boxberry utilizza la propria directory interna della città con i propri codici. Il nostro BoxberryCarrier determina innanzitutto la città dell'acquirente, trova il suo codice nella directory Boxberry in base al nome e al codice postale, e solo successivamente calcola il costo di consegna. Se la città non viene trovata (cosa che accade nelle piccole città), Boxberry semplicemente non appare nella matrice di consegna e l'acquirente può scegliere un altro corriere.

Una cosa interessante che ho notato nel corso degli anni di lavoro con le consegne è che i clienti sono molto fedeli al "loro" corriere. Alcune persone scelgono per principio solo SDEK, perché c'è un comodo punto di ritiro vicino a casa loro. Alcune persone preferiscono Boxberry perché consegnano più velocemente nella loro regione. Alcune persone amano le linee Business perché consegnano in modo affidabile carichi pesanti. E il compito del negozio non è imporre all'acquirente un corriere specifico, ma dare una scelta. Più opzioni ci sono, maggiore è la probabilità che l'acquirente trovi ciò che gli si addice e completi l'ordine.

Ma c'è un'altra faccia della medaglia. Ogni operatore aggiuntivo implica chiavi API aggiuntive che devono essere ottenute e configurate. Per SDEK è necessario registrare un accordo e ottenere l'accesso all'API. Per Boxberry: prendi un gettone. Per le linee aziendali: stipula un contratto e ricevi una chiave API. Per Russian Post: registrati su otpravka.pochta.ru e ricevi un token di autorizzazione. Per KIT è lo stesso. Non possiamo fare questa parte per te: è un processo tra te e la compagnia di spedizioni. Ma possiamo - e lo facciamo - fornire istruzioni chiare nelle impostazioni del plugin su dove e come ottenere ciascuna chiave, con collegamenti diretti alle pagine di registrazione.

Sai qual è la parte migliore? Il metodo is_configered() in ciascun operatore controlla se le chiavi API sono configurate. In caso contrario, il corriere semplicemente non partecipa al calcolo. Ciò significa che puoi prima collegare solo SDEK e Boxberry e poi, quando sei d'accordo con Business Lines e KIT, aggiungerli semplicemente inserendo le chiavi nelle impostazioni. Nessuna riconfigurazione, nessun test ripetuto. Il sistema preleverà automaticamente i nuovi corrieri e inizierà a mostrarli alla cassa.

KIT e Linee Business - per chi trasporta carichi pesanti

C'è un segmento di mercato che SDEK e Boxberry non servono molto bene: si tratta di carichi grandi e pesanti. Una tanica di olio motore da 20 litri pesa circa 18 chilogrammi. Un barile da 200 litri pesa già circa 200 chilogrammi. Pallet di oli - 500-800 chilogrammi. Tali carichi richiedono vettori specializzati in carichi consolidati e dotati di terminali per la ricezione di spedizioni di grandi dimensioni.

KIT (Industrial Transportation Company) è uno dei leader nel segmento del trasporto merci interurbano su strada. Hanno più di cinquecento terminal in tutta la Russia e sopportano bene carichi da 20 a 20.000 chilogrammi. Per i nostri clienti che vendono oli e lubrificanti industriali, il KIT risulta spesso essere la scelta migliore in termini di rapporto prezzo/velocità per le spedizioni interurbane.

Business Lines è un altro attore importante in questo segmento, con più di mille terminali e filiali in tutta la Russia. La loro API consente di calcolare il costo della consegna sia al terminal che alla porta del destinatario, tenendo conto dei servizi aggiuntivi: assicurazione, imballaggio rigido, sollevamento a terra.

Quando abbiamo integrato KIT e Business Lines, ci siamo trovati di fronte al fatto che le loro API sono strutturate in modo completamente diverso da quelle di SDEK o Boxberry. Hanno un modello di autorizzazione diverso, un formato di richiesta e risposta diverso e una logica diversa per determinare i terminali. Ma è proprio questo il valore di un'unica interfaccia: tutte queste differenze sono nascoste all'interno di specifiche classi di operatori. Dall'esterno, per il sistema di calcolo della consegna, tutti i corrieri sembrano uguali: chiamiamo calcola(), otteniamo il prezzo e la scadenza. Chiamiamo get_terminals() e otteniamo un elenco di punti di ritiro. Tutto è uniforme, tutto è prevedibile.

Per il proprietario di un negozio che vende beni pesanti, la presenza di KIT e Business Line nello stesso plugin dove sono già installati SDEK e Boxberry non è solo comodità. Si tratta di un'espansione della geografia di consegna e di una riduzione dei costi per l'acquirente finale. Perché per inviare un ordine da 100 chilogrammi tramite SDEK il costo può essere di diecimila rubli e tramite KIT - tremila. E quando l'acquirente vede entrambe le opzioni fianco a fianco alla cassa, fa una scelta informata e non ha la sensazione che il negozio stia cercando di guadagnare con la consegna.

Sento spesso dai proprietari dei negozi: "Perché mi servono KIT o Business Line? Ho piccoli beni, SDEK e Boxberry sono sufficienti." E nella maggior parte dei casi questo è vero. Ma ecco cosa ho notato: non appena il negozio inizia a crescere ed espandere il proprio assortimento, prima o poi compaiono prodotti per i quali SDEK e Boxberry non sono la scelta migliore. E se a questo punto hai già un plugin con supporto per KIT e Business Line, ti basterà procurarti le chiavi API e inserirle nelle impostazioni. In caso contrario, devi cercare un nuovo plugin, acquistarlo, configurarlo, testarlo e sperare che non entri in conflitto con quelli esistenti.

Caching e prestazioni: far funzionare il checkout

Ho già menzionato il caching, ma voglio approfondirlo perché è un argomento critico per qualsiasi negozio online. Ogni richiesta all'API di un operatore è una richiesta di rete che richiede da duecento millisecondi a due secondi, a seconda dell'operatore e di quanto sono occupati i suoi server. Se hai cinque operatori collegati e per ognuno devi calcolare due opzioni (corriere e punto di ritiro), si tratta di dieci richieste di rete. Coerentemente: si tratta di dieci o venti secondi di attesa alla cassa. In parallelo, sono due o tre secondi, ma il carico sul tuo server è ancora significativo.

Il nostro approccio consiste nel memorizzare nella cache i risultati dei calcoli per dieci minuti (parametro configurabile cache_ttl). La chiave cache è formata dai parametri dell'ordine: città di spedizione, città di ricevimento, peso, valore dichiarato. Se l'acquirente aggiorna la pagina o va nuovamente alla cassa con lo stesso set di prodotti, i risultati del calcolo vengono restituiti immediatamente dalla cache. Se modifica la quantità di merce o l'indirizzo di consegna, la cache viene invalidata e il calcolo viene eseguito nuovamente.

Dieci minuti rappresentano un compromesso ragionevole tra rilevanza dei dati e prestazioni. Le tariffe delle compagnie di trasporto non cambiano ogni minuto. Possono cambiare una volta al giorno, una volta alla settimana o una volta al mese. Una cache di dieci minuti garantisce che l'acquirente riceva il prezzo corrente, ma il checkout non verrà rallentato a causa di richieste ridondanti all'API.

C'è un altro aspetto legato alla performance a cui pochi pensano. Quando utilizzi cinque plugin di consegna separati, ognuno di essi include le proprie classi PHP, i propri hook WordPress, i propri gestori AJAX. Si tratta di un carico aggiuntivo sul server per ogni richiesta, anche se l'acquirente non è nella pagina di pagamento. Nel nostro plugin, tutti i corrieri sono classi PHP leggere che vengono caricate e inizializzate solo quando sono effettivamente necessarie, cioè durante il calcolo della consegna. Non aggiungono hook a ogni pagina del sito, né includono script sulle pagine in cui non è necessaria la consegna.

Cosa significa tutto questo per la tua azienda?

Ho iniziato questo articolo con la storia del proprietario di un negozio di lubrificanti e voglio ritornare sull'argomento. Dopo essere passato da cinque plugin separati al nostro modulo di consegna, sono successe alcune cose. Il risparmio sugli abbonamenti ammontava a circa trentamila rubli all'anno. Il tempo di caricamento del checkout è stato ridotto da cinque secondi a un e mezzo. Il numero di chiamate di supporto relative alla consegna è diminuito del quaranta per cento. E, cosa forse più importante, non teme più gli aggiornamenti di WordPress, perché ora ha un plugin invece di cinque e della sua compatibilità è responsabile un solo team invece di cinque sviluppatori diversi.

Ma non voglio dare l'impressione che la nostra soluzione sia perfetta per tutti. Se hai un piccolo negozio con venti ordini al mese e l'unico corriere è SDEK, probabilmente ti basterà un plugin gratuito per SDEK. Il nostro modulo di consegna entra in gioco quando hai diversi corrieri, diversi magazzini di spedizione, quando la velocità di pagamento e l'uniformità dell'esperienza del cliente sono importanti per te. Quando è necessaria l'integrazione con 1C per sincronizzare gli stati. Quando vendi sia beni leggeri (SDEK, Boxberry, Russian Post) che pesanti (KIT, Business Lines) e vuoi che tutto funzioni come un unico meccanismo.

C'è un altro argomento a cui ho pensato di recente. Il mercato dei servizi di trasporto in Russia sta cambiando. Appaiono nuovi vettori, quelli vecchi cambiano le loro condizioni, alcuni lasciano determinate regioni. Quando si dispone di un'architettura di interfaccia con un unico operatore, adattarsi a questi cambiamenti è rapido e indolore. Hai bisogno di aggiungere un nuovo operatore? Crea una nuova classe che implementa CarrierInterface. Hai bisogno di disabilitare il corriere? Rimuoviamo le sue chiavi API dalle impostazioni e semplicemente smetteranno di essere visualizzate al momento del pagamento. Hai bisogno di aggiornare la tua integrazione con un operatore che ha modificato la sua API? Aggiorniamo una classe e lasciamo stare il resto. Questa è una flessibilità che non puoi ottenere con un mucchio di plugin disparati.

Ho discusso a lungo se scrivere questo articolo perché l'argomento delivery mi sembra noioso. Questa non è intelligenza artificiale, né blockchain, né una tecnologia sofisticata. Ma sai una cosa: la consegna influisce direttamente sul denaro. Per la conversione alla cassa, per i costi di supporto, per la fidelizzazione dei clienti, per la scalabilità aziendale. E quando trovi una soluzione che rende la consegna più semplice, veloce ed economica, potrebbe non sembrare così bello in una conferenza, ma questo è esattamente ciò di cui le vere aziende hanno bisogno.

Continuiamo a sviluppare il modulo di consegna. I piani includono l'espansione dell'elenco dei corrieri, una più profonda integrazione con l'API per la creazione automatica delle richieste e una mappa interattiva con una visualizzazione visiva di tutti i punti di ritiro alla cassa. Ma già adesso quello che abbiamo - cinque corrieri, un'unica interfaccia, indirizzi FIAS, una matrice di checkout, tracciamento e integrazione con 1C - copre le esigenze della stragrande maggioranza dei negozi WooCommerce in Russia.

Un'ultima cosa. Spesso le persone mi dicono: “All in one significa che se si rompe il plugin, si rompe tutto”. Una giusta preoccupazione. Ma siamo onesti: se hai cinque plugin separati e uno di essi è rotto, anche parte del tuo checkout sarà rotta. E se due su cinque sono rotti, stai ancora cercando freneticamente una soluzione. La differenza è che con un plugin hai un team di supporto, un canale di feedback, un processo di aggiornamento. E se qualcosa va storto, sai a chi rivolgerti. Invece di capire quale dei cinque plugin è responsabile del conflitto, scrivici e noi risolveremo il problema. Non è un mondo perfetto, ma è un mondo in cui i problemi vengono risolti più velocemente.

Prova COS WP Woo - 14 giorni gratis. Un plugin invece di cinque per la consegna, più altri quaranta moduli per il tuo negozio WooCommerce. Collega SDEK, Boxberry, Business Lines, Russian Post e KIT in una sera, non in una settimana. Configuralo una volta e dimentica il mal di testa della consegna.