ენა
აქციის დაწყებამდე ყველაფერი შეიძლება დამაჯერებლად გამოიყურებოდეს: მთავარი გვერდი იხსნება, პროდუქტები კალათაში ემატება, მონიტორინგზე კი მწვანე ნიშნებია. მაგრამ მაღაზიისთვის გადამწყვეტი მომენტი შემდეგ მოდის - როცა მომხმარებელი შეკვეთას ამთავრებს და გადახდის პასუხს ელოდება. სწორედ ამ გზას სჭირდება ცალკე რეპეტიცია.
წარმოიდგინეთ პირობითი მაღაზია, რომელსაც ერთი საღამოს განმავლობაში ჩვეულებრივზე მეტი შეკვეთის მიღება უნდა. მისთვის სასარგებლო კითხვა არ არის მხოლოდ „რამდენ ვიზიტორს გაუძლებს ჰოსტინგი?“. საჭიროა ვიცოდეთ, რამდენი შესყიდვა სრულდება, სად წყდება გზა და ვის ეკისრება რეაგირება, თუ შეკვეთა გაიჭედა. ქვემოთ განხილული სცენარი მეთოდის ახსნაა და არა SERVER1-ის კლიენტის ისტორია.
მაღაზია შეკვეთის დასრულებისას შეამოწმეთ
ჩამოწერეთ მთავარი სცენარები: სტუმარი ათვალიერებს პროდუქტებს, ირჩევს ვარიანტს, იყენებს კუპონს, ცვლის რაოდენობას, გადადის checkout-ზე და იღებს შეკვეთის დადასტურებას. ცალკე სცენარია ანგარიშში შესული მომხმარებელი, რომლის ფასდაკლება, მისამართი ან კალათა პერსონალიზებულია.
ყოველ სცენარს დაუკავშირეთ ბიზნესშედეგი. შეკვეთის ღილაკის გამოჩენა ჯერ არ ნიშნავს, რომ გადახდა, მარაგი და ელფოსტა სწორად დამუშავდა. ერთ-ერთი მთავარი შემოწმებაა, განმეორებით დაჭერამ დუბლირებული შეკვეთა ან ოპერაცია ხომ არ შექმნა.
მოწყობილობის შეცვლაც მნიშვნელოვანია. ოფისის კომპიუტერზე გავლილი სცენარი ვერ ჩაანაცვლებს მობილურ ქსელში შესრულებულ გზას. შეამოწმეთ ფორმის შევსება, მიწოდების ვარიანტი და შეცდომის შემდეგ დაბრუნება. თუ მომხმარებელს თავიდან უწევს ყველაფრის შეყვანა, მხოლოდ სერვერის გამართვა ამ დანაკარგს ვერ მოაგვარებს.
სწრაფი კატალოგი კარგი დასაწყისია. მზადყოფნის მტკიცებულება კი სწორად დასრულებული შეკვეთაა.
ქეში იქ დაგეხმარებათ, სადაც საზღვარი სწორადაა გავლებული
WooCommerce-ის Cart, Checkout და My Account გვერდებს პერსონალიზებული ინფორმაცია აქვთ. page cache-ისა და CDN-ის შესაბამისი გამონაკლისები გადაამოწმეთ არსებული კონფიგურაციით. ქეშის გამორთვა მთელ საიტზე ავტომატური გამოსავალი არ არის: კატალოგის საჯარო გვერდებსა და პერსონალიზებულ პასუხებს განსხვავებული წესები სჭირდება.
ორი დამოუკიდებელი სატესტო სესიით დარწმუნდით, რომ ერთი მომხმარებლის კალათა მეორეს არ ეჩვენება. გამოცადეთ შესვლა, გამოსვლა, ცარიელი კალათა, კუპონი და პროდუქტის ვარიანტები. შეცვლილი ქეშის წესი ჯერ staging-ში გადაამოწმეთ და მხოლოდ შეთანხმებული რელიზით გადაიტანეთ.
რეპეტიციას სჭირდება პასუხი: ვაგრძელებთ თუ ვჩერდებით?
მოამზადეთ საიტის ასლი და გადაამოწმეთ, რომ ის იყენებს სატესტო გადახდის რეჟიმს. შეამოწმეთ ელფოსტა, კურიერის, საწყობისა და CRM ინტეგრაციებიც: საცდელი შეკვეთა მათთვის ნამდვილ შეკვეთას შეიძლება ჰგავდეს. მომხმარებლების პერსონალური ინფორმაცია გამოიყენეთ მხოლოდ საჭირო უფლებამოსილებით; სადაც შესაძლებელია, ჩაანაცვლეთ სატესტო მონაცემებით.
Staging საჯარო ძიებაში არ უნდა ჩანდეს. წვდომა შეზღუდეთ ავტორიზაციით და მხოლოდ robots.txt-ზე ნუ დაეყრდნობით. ტესტის დაწყებამდე გუნდის წევრმა უნდა დაადასტუროს გარემოს მისამართი, payment sandbox და გამავალი შეტყობინებების უსაფრთხო მარშრუტი.
საწყისად შეინახეთ ჩვეულებრივი დატვირთვის სურათი. გაზრდილი თანადროული სესიების შემოწმება აწარმოეთ მხოლოდ უფლებამოსილ staging გარემოში, შეთანხმებული მაქსიმუმითა და შეწყვეტის პირობით. საერთო ჰოსტინგზე ან სხვა კლიენტებთან გაზიარებულ სერვერზე თვითნებური დატვირთვის ტესტი დაუშვებელია.
ტესტის დასასრულს შეუდარეთ ერთმანეთს ის, რასაც მყიდველი ხედავს, მაღაზიის შეკვეთის სტატუსი და გადახდის პროვაიდერის sandbox პასუხი. ეს სამი სხვადასხვა სიგნალია. კლიენტისთვის ნაჩვენები წარმატების გვერდი თავისთავად არ ამტკიცებს, რომ ყველა შიდა სტატუსიც სწორია. ასევე, გადახდის შეცდომამ არ უნდა დატოვოს დაუდგენელი შეკვეთა, რომლის განმეორებასაც მომხმარებელი შემთხვევით შეძლებს.
ჩაწერეთ მოკლე გადაწყვეტილება: რა გამოცადეთ, რა მოცულობით, რა დარჩა გადასამოწმებელი და რა მდგომარეობაში შეწყდება აქცია. მაგალითად, გადახდის განმეორებითი გაურკვეველი პასუხი შეიძლება უფრო მნიშვნელოვანი აღმოჩნდეს, ვიდრე კატალოგის მცირე შენელება. მისაღები ზღვარი ბიზნესმა და ტექნიკურმა პასუხისმგებელმა წინასწარ უნდა შეათანხმონ.
აქციის საღამოს ახალი ექსპერიმენტის დრო აღარ არის
ჰიპოთეზურ მაღაზიას კამპანიაში 600 ვიზიტორი ჰყავს საათში. თანაბარი განაწილებით ეს საშუალოდ 10 ვიზიტორია წუთში, მაგრამ ერთდროული მომხმარებლების რაოდენობა ამ რიცხვიდან არ დგინდება: ისინი საიტზე სხვადასხვა დროს ჩერდებიან და სხვადასხვა რაოდენობის მოთხოვნას ქმნიან. ერთ წუთში რამდენიმე checkout შეიძლება უფრო მძიმე იყოს, ვიდრე მრავალი ქეშირებული პროდუქტის ნახვა.
თუ კატალოგი სწრაფია, checkout კი ნელდება, ჯერ შეამოწმეთ plugin-ის გარე მოთხოვნები, database query-ები და payment integration-ის რეაგირება. მეტი RAM გარე სერვისის დაგვიანებას ვერ აგვარებს. VPS-ის შეფასება გამართლებულია, როცა გაზომვა აჩვენებს კონკრეტულ რესურსულ ან მართვის საჭიროებას.
კამპანიამდე განსაზღვრეთ ცვლილებების შეჩერების პერიოდი და პასუხისმგებელი პირი. backup-ის არსებობასთან ერთად მნიშვნელოვანია მისი თარიღი, მოცულობა და უსაფრთხო გარემოში აღდგენის შემოწმება. სრული database rollback-ით შეიძლება წაიშალოს backup-ის შემდეგ მიღებული ნამდვილი შეკვეთები, ამიტომ ინციდენტისას მონაცემების შენარჩუნების გეგმა ცალკე გჭირდებათ.
რეპეტიციის შემდეგ შეცდომები დაალაგეთ მომხმარებლის გზის მიხედვით. ჯერ მოაგვარეთ შეძენის შემაფერხებელი პრობლემა, შემდეგ - კატალოგის კომფორტი. ასე გუნდი ერთდროულად ბევრ პარამეტრს აღარ ცვლის და უფრო ადვილად ხედავს, რომელი ცვლილება აღმოჩნდა სასარგებლო. თუ რამდენიმე ცვლილება ერთად გაკეთდა, შედეგის მიზეზსაც მეტი სიფრთხილით უნდა მიუდგეთ.
თუ მაღაზიისთვის გარემოს არჩევას იწყებთ, WordPress ჰოსტინგის განხილვას დაურთეთ ეს სცენარი. Managed VPS-ის საჭიროება დაასაბუთეთ დატვირთვითა და მართვის მოთხოვნებით. მხოლოდ მოახლოებული აქცია სერვერის გაზრდის საკმარისი არგუმენტი არ არის.
შემდეგი საკითხია თვითონ გარემოს შერჩევა: WordPress და WooCommerce ჰოსტინგი: რას უნდა მოიცავდეს სპეციალიზებული გარემო.
ტესტირების და ქეშის გამონაკლისების დეტალები გადაამოწმეთ პირველწყაროებში: WooCommerce - Testing orders; WooCommerce - Caching configuration.
