Pertama, sedikit mengomel :) Cepat atau lambat, toko online mana pun memiliki pertanyaan untuk menyiapkan keranjang yang ditinggalkan. Statistik dan perasaan kehilangan uang mengisap di perut tidak menyayangkan siapa pun.
Persentase keranjang terlantar dari 2006 hingga 2017
SumberPersentase keranjang terlantar untuk kuartal pertama 2018 menurut industri:
SumberPada saat yang sama, terlepas dari statistik yang tersedia secara umum, sebagian besar toko online tidak menggunakan fitur yang tersedia dan tidak menghubungkan keranjang yang ditinggalkan. Sebuah studi "rumah" baru-baru ini dari EmailSoldiers jelas menunjukkan bahwa sebagian besar toko tidak peduli sama sekali.
Statistik terkini untuk keranjang terlantar yang terhubung
SumberPada saat yang sama, semua orang (dan kami juga bukan orang suci) mengejar lalu lintas, menjalankan iklan dan materi iklan, tetapi bahkan tidak mencoba mengembalikan orang yang bangkrut pada saat terakhir.
Namun dalam iterasi pertama Anda bisa mendapatkan peningkatan pesanan menggunakan surat tanpa konten dinamis, Anda hanya perlu mengkonfigurasinya. Berusaha hanya sekali sehingga di latar belakang itu menghasilkan uang - bukankah ini dongeng?
Secara alami, surat dengan konten dinamis tempat barang dari keranjang ditarik dapat berfungsi lebih baik. Atau mungkin anak kucing lain dengan mata sedih akan lebih berpengaruh bagi audiens Anda. Atau Anda menarik barang-barang yang direkomendasikan ke barang-barang di keranjang dan memastikan bahwa barang-barang tersebut dibeli lebih sering dari surat dan menambah rata-rata cek. Atau Anda akan dapat membuat serangkaian surat dari mana konversi akan lebih besar.
Anda dapat meningkatkan dan menguji surat dari keranjang yang ditinggalkan ke cita-cita yang tidak dapat dicapai, tetapi surat yang pernah dikonfigurasikan sudah jauh lebih baik daripada tidak sama sekali.
Konversi untuk keranjang yang ditinggalkan menurut RetailRocket
SumberMaka, Kamerad
Artem Aleksandrov dan saya mulai memperkenalkan keranjang dari dua sisi.
Implementasi teknis
TOR untuk integrasi
Jelaskan secara singkat esensi dari tugas tersebut.
Tugas: sambungkan kereta yang ditinggalkan untuk situs xxx.xx dengan layanan pengiriman Mailchimp
Kami memberikan semua materi yang diperlukan.
Kunci API: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-usXX
Di mana mendapatkan kuncinya?
→
Kami memberikan tautan ke dokumentasiID sheet tempat kami menghubungkan Store: XXXXXXXXXX
Di mana saya bisa mendapatkan lembar ID?
Layanan surat harus dibuat terlebih dahulu. Segera setelah permintaan API diterima oleh layanan pengiriman, pesan secara otomatis dihasilkan dan penerima ditambahkan ke antrian untuk dikirim.
Untuk kasus kami, kami memilih logika berikut untuk mengirim keranjang yang ditinggalkan:
pengguna yang berwenang di situs menambahkan barang ke keranjang, tidak menyelesaikan transaksi dan tidak menyelesaikan pesanan, keranjang tetap tidak berubah selama 1 jam. Setelah itu, permintaan dikirim ke Mailchimp, di mana email, komposisi pesanan pengguna, gambar produk, harga barang dan tautan ke keranjang pengguna ditransmisikan.
Templat Tata Letak
Saat membuat otomatisasi untuk keranjang yang ditinggalkan, mailchim segera bertanya apakah akan ada satu atau beberapa huruf dan menyarankan memilih toko yang terhubung.
Dalam templat dasar, mch menawarkan tiga pilihan:
- Keranjang yang ditinggalkan dengan barang dinamis
- Keranjang yang ditinggalkan dengan rekomendasi bahan makanan (perlu dikonfigurasi secara terpisah)
- Keranjang yang ditinggalkan tanpa barang (hanya surat teks)
Dalam tradisi terbaik, jika Anda punya waktu, Anda dapat membuat keranjang sendiri.
Produk dinamis tanpa gaya terlihat seperti ini (lupakan lekukan, mereka ditampilkan dengan buruk di sini):
<table> <tbody> *|ABANDONED_CART:[$total=3]|* <table> <tbody> <tr> <td> <a href="*|CART:URL|*" title="*|PRODUCT:TITLE|*" target="_blank"> <img src="*|PRODUCT:IMAGE_URL|*"> </a> </td> <td> *|PRODUCT:TITLE|* — *|PRODUCT:PRICE|* </td> </tr> </tbody> </table> *|END:ABANDONED_CART|* </tbody> </table> *|END:ABANDONED_CART|* </tbody> </table>
Tampaknya jika Anda mengubah angka dalam variabel
* | ABANDONED_CART: [$ total = 3] | * , maka surat itu akan menampilkan jumlah barang yang berbeda, tetapi tidak, letakkan setidaknya 5, setidaknya 100, mch menolak untuk menunjukkan kuantitas lain.
Dan, yang juga sedikit aneh, variabel
* | PRODUCT: PRICE | * diganti dengan nilai format RUB288, dan untuk beberapa alasan juga tidak mungkin untuk mengubah ini, tetapi lebih lanjut tentang itu nanti.
Untuk perubahan, kami mencoba mengganti variabel dengan jumlah game dan dengan total biaya pesanan, yang kami kirimkan melalui api, tetapi mailchimp di sini mengatakan tidak. Baiklah, jadi itu.
Sepatah kata untuk programmer :)
Dengan mailchimp ada pengalaman historis integrasi dengan mandrill layanan pihak ketiga mereka, semuanya sederhana dan jelas di sana. Dokumentasi yang sangat ramah (tentu saja, dalam bahasa Inggris), tetapi tidak ada sisi yang kasar dan berhasil sejak tendangan pertama.
Juga, mekanisme berlangganan melalui formulir khusus telah diperkenalkan di situs kami. Di sini, kami sepenuhnya merasakan pernyataan dan pernyataan ambiguitas yang diremehkan. Bahasa Inggris bukan masalah bagi pengembang yang berpengalaman, tetapi pengetahuan dialek Klingon tidak tersirat secara default.
Data awal adalah: bahasa php7 dan kerangka kerja yii2, yang telah berkembang pesat dengan ekosistemnya. Yaitu Kami sudah memiliki 6 proyek kecil yang mencoba menggunakan komponen umum baik di backend dan front-end. Dengan demikian, pelaksanaan tugas apa pun membutuhkan penyelesaian proyeknya secara independen, tetapi ini tidak menyiratkan kerangka kerja independensi, karena Anda harus membayarnya dengan jam kerja manusia, yang selalu ada kekurangan.
Setelah menerima tugas integrasi, pertama-tama kita harus melihat-lihat. Apa yang diberikan kepada kita? Pertama, layanan mailchimp yang perlu Anda berteman. Kami pergi ke github dan melihat bahwa ada cukup banyak implementasi. Tapi pilihannya sederhana - paket paling populer dari bintang
1.5k (
drewm / mailchimp-api ).
Paket ini memberikan pembungkus sederhana atas interaksi-istirahat dengan penyimpanan surat. Kami hanya dapat memperoleh ini dengan logika kami.
Kedua, kami diberikan
dokumentasi . Berdasarkan dokumentasi, kami memiliki sumber daya Toko dengan sumber daya bersarang: Keranjang, Pelanggan, Pemesanan, Produk, aturan Promo. Untuk keranjang yang ditinggalkan tanpa produk yang direkomendasikan, kami hanya membutuhkan Produk, Keranjang, dan Pelanggan. Keranjang, pada gilirannya, terdiri dari rangkaian garis Keranjang, dan Produk berisi varian Produk.
Kami mendekomposisi tugas sebagai berikut:
- Unggah data toko ke Toko
- Unduh semua produk yang dapat dibeli di Produk
- Siapkan pemuatan keranjang dengan pengguna sesuai jadwal
Ok, ayo pergi. Pertama-tama, kami mengambil esensi dari "toko". Kami memutuskan untuk segera menggunakan versi uji dan tempur toko dan, tergantung pada variabel lingkungan yang bertanggung jawab untuk mode perdananya, kami bekerja baik dengan satu toko atau dengan yang lain.
Untuk mengunduh data toko, kami mengetuk permintaan pos di / ecommerce / store dengan serangkaian parameter berikut:
[ 'id' => 'dev.***.ru', 'list_id' => '****', 'name' => '*** - test', 'domain' => 'dev.***.ru', 'email_address' => 'admin@***.ru', 'currency_code' => 'RUB', 'primary_locale' => 'ru', 'money_format' => '₽', ]
Ada beberapa opsi lagi, tetapi semuanya tergantung pada kebutuhan. Karena kami tidak akan menggunakan detail kontak toko dalam surat, kami tidak mengisi bidang telepon, alamat, zona waktu, dll.
Tapi kejutan kecil menunggu kami. Bidang money_format tampaknya dibuat khusus untuk kemampuan menyajikan harga dalam format yang nyaman bagi kami. Tetapi ketika membangun templat keranjang yang ditinggalkan, kepala surat dengan keras kepala mengganti RUB sebelum nomor itu. MailChimp, hentikan!
Setelah mengunduh, kita dapat memeriksa data menggunakan permintaan-mendapatkan di alamat / ecommerce / store untuk melihat semua toko yang dimuat, atau / ecommerce / stores / {id} untuk mendapatkan data di toko tertentu.
Sekarang Anda dapat menambahkan semua data lainnya, karena Store adalah titik root di pohon data kami, karena kami akan mengunggah semua data lain ke toko tertentu.
Jadi, agar KIA bisa mengganti barang dalam keranjang yang ditinggalkan, ia perlu memberi makan barang-barang ini. Untuk melakukan ini, kami memiliki alamat / ecommerce / store / {store_id} / produk, tempat kami mengirim permintaan pasca untuk membuat produk dalam sistem.
[ 'id' => '742', 'title' => '', 'handle' => 'kastrulya', 'url' => 'http://***.ru/catalog/kastrulya/', 'description' => ' — . , . , ! !', 'type' => '', 'vendor' => ' ', 'image_url' => 'http://***.ru/images/742/product.png', 'variants' => [ [ 'id' => '742', 'title' => '', 'url' => 'http://***.ru/catalog/kastrulya/', 'price' => 890, 'sku' => 'KA453', 'inventory_quantity' => 1000, 'image_url' => 'http://***.ru/images/742/product.png', 'visibility' => 'visible', ], ], ]
Apa yang luar biasa? Pertama, setiap produk harus terdiri dari setidaknya satu penawaran produk. Intinya, Produk adalah wadah untuk memuat penawaran produk. Selain itu, id produk dan penawaran produk dapat bersinggungan, karena ini adalah sumber daya yang berbeda dalam api KIA.
Dan di sini pernyataan tentang dokumentasi KIA dimulai. Saya harus menebak, walaupun itu tidak sulit, tetapi Anda bisa melakukannya secara normal, dan tidak seperti biasanya.
Bidang pegangan telah dideskripsikan sebagai “pegangan suatu produk”. Ok, setelah berkonsultasi, kami memutuskan bahwa ini adalah bagian dari URL yang terkait dengan produk itu sendiri (cnc). Tapi ini dikonfirmasi hanya selama tes.
Anda juga dapat melampirkan serangkaian gambar ke produk, tetapi kami memutuskan bahwa itu tidak akan berguna bagi kami dan oleh karena itu hanya gambar utama yang dimuat ke produk dan untuk setiap penawaran produk.
Dan di sini kami punya masalah, karena alasan tertentu barang tidak muncul di templat bagan pos.
Kami mulai menggali ke dermaga untuk Produk. Dan mereka menemukan bidang visibilitas dengan deskripsi mewah:
Nah, ketik String! Dan apa yang bisa ditransfer ke sana? Mengapa tidak mungkin menggambarkan semua arti yang mungkin?! Saya dapat mengirim ke sana, misalnya, "tunjukkan padaku pls!".
Untungnya ada contoh permintaan!
Ya, ini tidak membatalkan masalah. Saya tidak tahu nilai lain apa yang mungkin berguna.
Semua orang diatasi dengan ini! Sekarang pemasar email dapat memverifikasi ketersediaan barang dalam sistem melalui membangun templat dengan partisipasi barang atau semuanya melalui permintaan dapatkan yang sama menggunakan konsol.
Selanjutnya, kita dihadapkan dengan tugas memuat keranjang yang ditinggalkan di KIA. Awalnya, 2 pilihan muncul di benak:
- Setiap kali Anda mengganti keranjang (menambah / menghapus barang), kami mengulangi tindakan ini dalam KIA. Dari minus - sejumlah besar permintaan ke layanan eksternal segera menunjukkan dirinya.
- Sekali setiap n menit, perhatikan keranjang yang belum berubah lebih dari satu jam yang lalu. Lalu kami kirim ke KIA. Hanya ada satu masalah - untuk melacak keranjang yang dilanjutkan setelah mereka pergi ke KIA.
Pertama, kami membuat permintaan ke database kami (selanjutnya disebut sebagai DB) untuk data kami di jendela dari 1 jam hingga 3. Mengapa 3? Satu jam setelah perubahan terakhir, kami mengirim keranjang ke sistem. Dalam KIA interval minimum yang mungkin untuk mengirim keranjang adalah 1 jam. Karena itu, secara teori, setelah 2 jam ± 5 menit, surat akan dikirim. Jadi 3 jam adalah nilai bahkan dengan margin.
Setelah menerima data dari database, kami membuat permintaan dapatkan di alamat / ecommerce / store / {store_id} / troli. Dengan demikian, kami mendapatkan semua keranjang yang duduk di sistem e-commerce dan menunggu giliran mereka untuk mengirim (atau sudah dikirim). Mengapa kita membutuhkan ini? Diperlukan untuk sinkronisasi dengan data kami. Kami akan mengirim semua keranjang yang diterima dari basis data, tetapi kami perlu menghapus keranjang yang tidak lagi dalam kisaran 1-3 jam. Setelah 3x - sudah data yang tidak relevan. Hingga satu jam - keranjang yang bisa diperbarui lagi, atau memesan.
Untuk menghapus, kita hanya perlu menemukan perbedaan antara dua array / koleksi keranjang.
Setelah menerima keranjang yang perlu dihapus, kami mengirim permintaan penghapusan / ecommerce / stores / {store_id} / carts / {cart_id}.
Selanjutnya, kami mengambil keranjang untuk diunduh dan mengirimkannya melalui pos-permintaan ke sistem dalam satu siklus.
Parameter keranjang terlihat seperti ini:
[ 'id' => '1207', 'customer' => [ 'id' => '25', 'email_address' => 'email@example.com', 'opt_in_status' => false, ], 'currency_code' => 'RUB', 'order_total' => 1597, 'checkout_url' => 'http://***.ru/cart/abandoned/?cart=eyJpdGVtcyI6eyI1OTgwIjoxLCIzNDA0IjoxLCI3NzMiOjEsIjkwNTgiOjEsIjkwOTEiOjEsIjE4ODciOjEsIjc4NCI6MSwiNTExMSI6MSwiODA1MyI6MSwiMTk0MSI6MSwiNTQ0NSI6MSwiNzk1NCI6MywiOTA2NyI6NCwiOTA2NSI6NCwiNzg0MyI6MSwiOTA2NiI6M30sInByb21vY29kZSI6bnVsbH0%253D', 'lines' => [ 0 => [ 'id' => '123', 'product_id' => '5980', 'product_variant_id' => '5980', 'quantity' => 1, 'price' => 841, ], 1 => [ 'id' => '124', 'product_id' => '3404', 'product_variant_id' => '3404', 'quantity' => 1, 'price' => 756, ], ], ] ? //***.Ru/cart/abandoned/ keranjang = eyJpdGVtcyI6eyI1OTgwIjoxLCIzNDA0IjoxLCI3NzMiOjEsIjkwNTgiOjEsIjkwOTEiOjEsIjE4ODciOjEsIjc4NCI6MSwiNTExMSI6MSwiODA1MyI6MSwiMTk0MSI6MSwiNTQ0NSI6MSwiNzk1NCI6MywiOTA2NyI6NCwiOTA2NSI6NCwiNzg0MyI6MSwiOTA2NiI6M30sInByb21vY29kZSI6bnVsbH0% 253D', [ 'id' => '1207', 'customer' => [ 'id' => '25', 'email_address' => 'email@example.com', 'opt_in_status' => false, ], 'currency_code' => 'RUB', 'order_total' => 1597, 'checkout_url' => 'http://***.ru/cart/abandoned/?cart=eyJpdGVtcyI6eyI1OTgwIjoxLCIzNDA0IjoxLCI3NzMiOjEsIjkwNTgiOjEsIjkwOTEiOjEsIjE4ODciOjEsIjc4NCI6MSwiNTExMSI6MSwiODA1MyI6MSwiMTk0MSI6MSwiNTQ0NSI6MSwiNzk1NCI6MywiOTA2NyI6NCwiOTA2NSI6NCwiNzg0MyI6MSwiOTA2NiI6M30sInByb21vY29kZSI6bnVsbH0%253D', 'lines' => [ 0 => [ 'id' => '123', 'product_id' => '5980', 'product_variant_id' => '5980', 'quantity' => 1, 'price' => 841, ], 1 => [ 'id' => '124', 'product_id' => '3404', 'product_variant_id' => '3404', 'quantity' => 1, 'price' => 756, ], ], ]
Dan lagi, rubrik favorit kami adalah "tebak cara kerja bidang ini." Misalnya, dengan metode poking ilmiah, terungkap bahwa adalah mungkin untuk tidak membuat pembeli dengan permintaan terpisah. Diperlukan untuk mentransfer set bidang minimum yang diperlukan, dan itu akan secara otomatis dibuat jika tidak ada dalam sistem. Dalam kasus kami, kami membatasi diri untuk id, email, opt_in_status. Parameter terakhir bertanggung jawab untuk status langganan pengguna di lembar kami. Jika itu benar, maka ini berarti negara berlangganan, jika tidak transaksional.
Daftar produk dimuat tanpa masalah melalui larik Cart Lines, yang pada gilirannya adalah sumber daya entitas Cart. Yaitu kami dapat mengelola set ini secara terpisah dengan permintaan lainnya.
Yah, itu saja, sepertinya? Tapi tidak.
Saat menguji, kami perhatikan bahwa mengirim keranjang yang sama, hanya dikirimkan satu kali. Meskipun kami menghapusnya dari sistem dan mengunduh lagi. Tidak ada yang dikatakan di mana pun, tidak satu kata pun! Sebagai hasilnya, secara empiris, dengan bantuan beberapa ibu, kami mengambil sebagai dasar hipotesis bahwa keranjang dengan id yang sama dapat dikirim hanya sekali.
Di sini saya sepenuhnya setuju dengan pembuat bahwa pembatasan ini menyelamatkan kami dari pengguna yang melakukan spam. Tapi tulis tentang itu! Kami tidak membutuhkan pencarian, kami memiliki cukup banyak kesalahan mistik dalam kode yang kami tulis.
Setelah kami melakukan semua ini, KIA mulai mengirimi kami surat-surat indah tentang keranjang yang ditinggalkan. Dan kemudian pertanyaan kedua muncul. Jika pengguna telah melempar keranjang dan kembali dari surat ke akunnya sendiri, yaitu, ia diizinkan pada saat mengklik tautan, maka ia akan masuk ke keranjangnya tanpa masalah. Dan ternyata surat itu mengatakan "hidup! ambil keranjangmu kembali! ", dan ketika kita menyeberanginya kita berkata," oops, ada yang hilang! Kami tidak menyentuh apa pun! Itu sendiri! "
Diputuskan untuk menyandikan komposisi keranjang menjadi string dan meneruskannya ke checkout_url saat mengirim keranjang ke KIA. Dan ketika Anda pergi ke situs, tangkap garis ini, decode dan buang semua barang di keranjang, jangan lupa untuk mengatur ulang sepenuhnya sebelum itu.
Jadi, apa pun browser yang kami kirimkan kepada pengguna, ia mendapatkan keranjangnya, seperti yang kami janjikan. Satu-satunya negatif adalah bahwa ia hanya dapat masuk. Tetapi untuk mengotorisasi melalui tautan adalah perilaku buruk, dan memang itu adalah bisnis yang berbahaya, pertama-tama untuk klien kami.
Apa hasilnya? Pada prinsipnya, tidak ada masalah khusus selama implementasi, karena sangat sering tanggapan KIA membantu kesalahan terkait dengan validasi bidang yang ditransfer. Tetapi akan ada lebih sedikit lagi dari mereka jika mereka biasanya secara manusiawi menggambarkan semua seluk-beluk pekerjaan KIA ini dan menggambarkan bidang-bidang tersebut secara lebih rinci.
Laporkan pengaturan di Google.Analytics
Untuk melacak keberhasilan seluruh operasi, Anda harus mengonfigurasi dan melihat laporan secara analitik secara berkala. Bayangkan bahwa semua orang, seperti orang dewasa, memiliki e-commerce yang terhubung, jika tidak keajaiban tidak akan berhasil :)
Untuk mengumpulkan laporan baru untuk keranjang yang ditinggalkan, buka "Laporan Saya":
Selanjutnya "Tambah laporan":
Dan setelah itu kita tambahkan parameter yang akan kita lacak. Kami memutuskan bahwa kami akan melihat keranjang yang ditinggalkan dalam konteks kota, Anda mungkin memiliki visi yang berbeda.
Untuk mailchamp, kampanye standar untuk keranjang yang ditinggalkan adalah ABANDONED_CART_EMAIL, kami menggantinya di filter dan mendapatkan laporan.
Itu semua garpu!
Sekarang Anda dikonfigurasikan untuk mengirim keranjang yang ditinggalkan dan laporan yang dengannya Anda dapat menyaksikan pembuangannya. Dan uji, uji, uji! ;)