Comparison of products, wish lists and brand analogues: three features for increasing the average check

Last week, the owner of an auto chemicals wholesale store wrote to me - one of those who had already outgrown Bitrix and migrated to WooCommerce, but was faced with an unpleasant discovery. “Oleg,” he says, “I have a catalog of sixteen thousand items, clients call and ask: how is your Shell Tellus S4 VX 32 oil different from Lukoil Geyser LT 32? But I can’t send them to the site, because there is simply no comparison of products. Ozone has it, Wildberry has it, even Leroy has it, but I don’t. There is no wishlist either. Managers keep lists of clients in Excel, can you imagine?” I present. And I hear this story about once every two weeks from different people. Only the names of the oils and the names of the owners change.

Here's the thing: WooCommerce out of the box is a brilliantly designed e-commerce engine, which at the same time does not do three basic things, without which no marketplace can live. Side-by-side product comparisons, wishlists with the ability to share a link, and automatic pages of competitors' brands. Three features that the buyer takes for granted because he is used to them on every major marketplace. When he comes to your site and doesn’t find the “Compare” button, he doesn’t think that you don’t have the plugin installed. He thinks you're a frivolous store. And this perception - “frivolous” - costs you money. Every day, every lost order, every client who left for the marketplace because it was “more convenient” there.

I've been developing and marketing online stores using WooCommerce for long enough to see how the landscape has changed. Five years ago, no one needed vishlists - people bought immediately or didn’t buy at all. Three years ago you could do without comparison if you had a narrow niche and the manager was ready to advise you over the phone. Today it's hygiene. If you have a B2B store with a catalog of thousands of SKUs and you don’t provide tools for self-selection, you are losing money. And not on those clients who go to competitors (although they do too), but on those who remain, but buy less than they could. The average bill is what suffers first. Because without comparison tools, the buyer takes the first product he comes across, instead of consciously choosing a more expensive and high-quality one. Without a wish list, he forgets about the items he wanted to order later. Without pages of analogues, he goes to Google and ends up with a competitor.

And today I want to tell you in detail how three modules in our COS WP Woo plugin solve this problem. Not theoretically - “but if you introduced comparison, it would be good.” Specifically, how each module is structured, what technical decisions we made and why, what it looks like for the buyer on the front end, and most importantly, how it affects your money. Without crutches, without a zoo of plugins and without annual licenses of one hundred dollars for each function.

When a comparison table outsells a manager

Let's start with the most obvious - product comparison. The idea is indecently simple: the buyer selects two, three or four products, presses a button and sees a table where all the characteristics are lined up opposite each other. Price, availability, SKU, description, and most importantly - technical attributes. Viscosity, pour point, flash point, density, GOST - all this is displayed line by line, and the buyer sees the difference instantly. There is no need to open three browser tabs and jump between them with your eyes, trying to keep numbers in your head. There is no need to call the manager and wait until he himself opens three product cards and starts reading the characteristics out loud, getting confused in the numbers.

When we were designing the comparison module in COS WP Woo, I specifically studied how the big players do it. Wildberries builds the table vertically - products in columns, characteristics in rows. Ozon does much the same, but adds highlighting of differences - what is different is highlighted in color. We went the classic route, which works well for industrial catalogs: a horizontal scrolling table, where on the left is the name of the characteristic, and on the right are the values ​​for each product. This works great on desktop, but on mobile devices the table will scroll horizontally, and this is absolutely expected behavior for any smartphone user - we are all used to swiping tables sideways. Above the table there is a header and a “Save as PDF” button. Under the title of each product there is a cross to remove from comparison. Everything is minimalistic and functional.

But the devil, as always, is in the details. And I want to go through five key details that make this comparison not only work, but actually useful for the buyer and for your business.

The first detail is dynamic attributes. When you compare two hydraulic oils, the only characteristics that matter are their viscosity at different temperatures, viscosity index, and pour point. When you compare two sets of filters, they are completely different: sizes, threads, pressure. Our module automatically collects a combination of all attributes of the compared products and displays them in a table. This means that the table is adapted to a specific set of products: if you compare oils, the table will contain attributes of oils, if filters - attributes of filters. If one product has the “Viscosity at 40°C” attribute and the other does not, there will be a dash next to the second product in this line. The buyer immediately sees: yeah, the characteristics of this product are not indicated, maybe it’s worth clarifying. Or maybe it means that the product has not been tested for this parameter. In any case, information for making a decision. The auto_attributes option is enabled by default, and I strongly recommend leaving it on.

The second detail is cookie-based storage of the comparison list. We deliberately did not link the comparison to the user account. Why? Because according to our data, seventy to eighty percent of online store visitors are unregistered guests. They came from Google, from Yandex, via a link from a colleague - and they do not have an account on your site. If comparison requires registration, you are losing your core audience. The list of products being compared is stored in a cookie named yith_woocompare_list - and yes, we are specifically using the same cookie name as YITH WooCommerce Compare. This is not done out of laziness, but for seamless migration: if you move from YITH to our plugin, the comparison lists of your current users are not lost. A person who added three products to comparison via YITH yesterday will open the same page with our plugin today and see the same three products. The cookie lives for thirty days, and if the buyer returns in a week, his list is in place.

The third detail is AJAX adding without reloading the page. The buyer flips through the catalog, sees an interesting product, clicks the “Compare” button - and the button instantly changes its state to “Added”, without reloading the page, without spinners, without losing the scroll position. A floating comparison panel appears at the bottom of the screen with the number of selected products and a “View Comparison” button. This is the very pattern of microinteraction that distinguishes a professional online store from a homemade one. And this is exactly the UX that marketplace users are accustomed to: clicked - added - continue to select - move on to comparison when ready. No interruptions in the selection process, no loss of context.

The fourth detail is a shortcode and a separate page. The comparison table is rendered via the yith_woocompare_table shortcode (YITH compatible) and can be placed on any WordPress page. But there are two modes of operation, and each of them serves a different purpose. Dynamic mode - a shortcode without parameters, takes a list of products from a cookie. This is the same “live” table that changes every time a product is added or removed. Static mode - a shortcode with explicitly specified product IDs, for example [yith_woocompare_table products="123,456,789"]. Static mode is ideal for landing pages and content marketing. I saw one of our clients create a “Construction Equipment Hydraulic Oil Comparison” landing page with a table of eight products, and this page consistently brings in search traffic because it answers a specific user query. Google loves structured content, and a comparison table is the perfect structured content.

The fifth detail is export to PDF. The "Save as PDF" button is right above the comparison table. For B2B clients, this is not just a convenience - it is a working tool. The purchasing manager compared three oils, saved the PDF, and sent it to the manager for approval or to the tender committee. No screenshots, no “let me list the characteristics in an email.” A clean, beautifully designed table with prices and technical data. Several of our clients noted that after adding PDF export, the number of completed applications increased - and this is logical: the easier it is for a buyer to collect and transfer information within their company, the faster the approval procedure goes and the faster the order is processed.

It’s worth mentioning separately about setting up table fields. By default, the image, title, price, “Add to Cart” button, description, article number and availability are displayed. But in the admin panel you can configure which fields to show and in what order. For an industrial B2B store, for example, a product description may not be needed in the comparison table - the article number, stock availability and technical characteristics are more important. For a clothing retail store, on the other hand, close-up images and price are important, and the SKU can be hidden. For an electronics store, the specifications come first, and the description comes last. This flexibility is not decorative, it actually affects conversion, because the buyer sees exactly the information that is relevant to making a decision in your specific niche. One client removed the description from the table and added weight and dimensions - and says that there are noticeably fewer requests for clarification, because logisticians immediately see the dimensional data.

Wish lists are not for desires, but for money

To be honest, when I first started working with e-commerce, I considered wish lists a decorative function. Well, a person added a product to “Favorites” - so what? He still won’t buy if he’s not ready right now. This is not a basket, but some kind of intermediate buffer that leads nowhere. I was wrong, and it took me several years and a lot of data to admit it. A wishlist is not about “I want to do it someday, maybe.” A wishlist is a deferred demand that is converted into a real purchase with the right trigger. The price has decreased - trigger. The product is back in stock - trigger. The end of the quarter is approaching and you need to master the budget for consumables - trigger. Each of these moments is a conversion point, and a wishlist makes it possible because it maintains a connection between the buyer and the product over the course of weeks and months.

The wishlist module in COS WP Woo is more serious than it might seem at first glance. This is not just an array of product_id written in the user meta. We have two separate tables in the database: wpaic_wishlists stores the lists themselves (yes, one user can have several of them - I’ll tell you more about this), and wpaic_wishlist stores products inside lists with the fields user_id, product_id, wishlist_id, sort_order and added_price. The last field is key for the entire vishlist monetization model. We remember the price of the product at the time it was added to favorites. For what? To then compare with the current price and send the buyer a notification of the reduction. But notifications will be a separate discussion - they deserve a detailed explanation.

Multiple listings are a feature I picked up from Amazon and adapted for a B2B context. On Amazon you can create a list “For the home”, “For the garden”, “New Year gifts” and so on. In a B2B environment, this works even more powerfully: “Consumables for April”, “Oils for a new machine”, “Spare parts for scheduled maintenance”, “For tender number 47”. Each list has its own name, privacy settings and a unique share_token of twenty-four characters for secure sharing. Yes, the buyer can create a list, fill it with products, set privacy and send a link to a colleague or buyer. He will open the link and see all the products without the need for registration - if the list is public or “available via link”. For wholesale purchases, this is fantastically convenient: a production engineer sits at a computer, compiles a list of necessary consumables, then sends a link to the accounting department, the accountant opens and places the order. No correspondence “send me the articles”, no tables in Excel.

List privacy works on three levels, each with its own use case. Private - visible only to the owner, these are personal notes, “I want to, but haven’t decided yet.” Shared - visible via a unique link with a token, ideal for sharing within a company or family. Public - visible to all site users if you decide to implement a gallery of public listings. For a retail store, public lists are gift wishlists: “what to give Maria for her birthday, here is her list.” For B2B, it is a communication tool between departments. I know of a case where customers of a lubricant distributor began creating shared lists and sending links via email instead of standard Excel requests. They actually used the wishlist as an order form, and this without any special setup or training - people themselves found a way to use the tool in the way that was most convenient for them. This is the best proof that the function is really needed.

On the front end, a wishlist is implemented through a heart button, which appears on the product card in the catalog and on the product page. Clicked - the product was added, the heart was filled with color, and the wpaic-wishlist-btn--active class appeared on the button. Clicked again - the product was deleted, the heart returned to its original state. The whole process is via AJAX, without reloading, via wp_ajax and wp_ajax_nopriv with nonce check. For authorized users, data is immediately written to the database. For guests, products are stored in localStorage or cookies - and here is the most important point: when a guest registers or logs into his account, his guest wishlist is automatically merged with the existing one. The merge_guest_items method takes all products from the guest storage and adds them to the user’s default list via INSERT IGNORE - that is, if the product was already in the wish list, a duplicate is not created. This is a seamless experience: the buyer wandered through the catalog without authorization, added products to favorites, then decided to register - and everything is in place, nothing was lost. So many competing plugins don't do this, and the buyer loses their list upon registration - imagine the disappointment.

A separate “Favorites” tab appears in your WooCommerce personal account - this is a real WooCommerce endpoint, registered via add_rewrite_endpoint. Twelve products per page with pagination, the ability to delete, go to the product page with one click. The order of products is configured via drag-and-drop: the buyer can drag products in the desired order, and the order will be saved through the update_sort_order method, which takes the product_id array and updates the sort_order field in the database. Trifle? For retail - maybe. But when a buyer of a large enterprise has forty to fifty items on the list, the ability to sort them by priority or into groups is a real time saver and reduces the risk of errors when placing an order.

Now about wishlist analytics, and this is my favorite part. In the admin panel of the plugin there is a section that shows the most popular products - those that are most often added to favorites. The get_analytics method returns the top 20 most liked products with the number of additions, current price and photo. Plus general statistics: how many unique users use wish lists, how many products have been added in total. This information is invaluable to marketers and category managers. If a product is often added to the wishlist, but rarely purchased, this is a clear signal of a barrier. Is the price too high? Not available? The description doesn't convince you? Is shipping too expensive? In any case, this is a specific product with a specific problem that needs to be responded to. Make a targeted promotion for this product, reduce the price by five percent, add reviews - and you will convert pent-up demand into live sales. Without wishlist analytics, you would not even know that there is a demand for this product.

Emails that sell for you

I thought for a long time whether it was worth highlighting notifications in a separate section or talking about them in the context of wishlists. I decided to highlight it because it is an independent and very powerful mechanic that deserves a separate analysis. The WishlistNotificationService module is responsible for two types of automatic email notifications: price reduction and product return in stock. Both work completely autonomously - without human intervention, without setting up email campaigns in Mailchimp or Sendinblue, without any external services or subscriptions. Everything is inside WordPress and WooCommerce, via standard wp_mail and WP Cron.

Price reduction works through daily cron task. The wpaic_wishlist_price_check hook works once a day and checks all products from wishlists, comparing the current price with the price at the time of addition - the same added_price field that I mentioned earlier. If the price has decreased by five percent or more, the buyer receives a neat HTML letter with a table: product name, old price crossed out, new price highlighted in green bold, discount percentage in red. The letter is adapted for mobile devices, the fonts are readable, the “Go to product” button is large and noticeable. The threshold of five percent is configured through the wpaic_wishlist_min_price_drop_pct option - you can make it ten for stores with large prices, or three for FMCG. The point of the threshold is to avoid spamming emails with minor fluctuations. If the price has decreased by half a percent due to exchange rate differences or VAT recalculation, this is not a reason to bother the buyer. But fifteen percent is already an event worth talking about.

Return to stock works fundamentally differently - it is an event trigger, not a schedule. As soon as WooCommerce changes the status of a product to instock via the standard hook woocommerce_product_set_stock_status, our module instantly finds all users who have this product in their wish list and sends each a personal letter. “Shell Helix HX8 5W-30 oil is back in stock!” — with a photo of the product, the current price and a CTA button “Go to product.” Instantly - this means within a minute after the status change, and not the next day according to the crown. Deduplication is implemented via WordPress transient with a key including user_id and product_id: one user receives a notification about a specific product no more than once every seven days. If a product blinks between instock and outofstock every day due to problems with 1C synchronization, the buyer will not be inundated with letters, he will only receive the first one.

You know what's most interesting? These trigger emails have a conversion rate that is many times higher than regular marketing emails. And this is logical, if you think about it: the letter does not come to an abstract subscriber with an abstract offer “we have discounts on everything,” but to a specific person who, with a specific action (adding to a wishlist), said “I’m interested in this product.” This is not spam, this is a service. The buyer added oil to favorites because it is expensive for him now, or he does not have a budget until the end of the month, or the product is out of stock. A month later, the price dropped by fifteen percent - and he received a letter. He doesn’t think “spam again, unsubscribe”, he thinks “oh great, I was just about to order, thanks for the reminder.” This is trigger marketing in its purest form, built into a plugin without any external integrations or monthly fees for the email platform.

For the B2B segment, notification of returns in stock is especially critical, and I want to explain why with a specific example. Industrial oils, specialized lubricants for gearboxes, and hydraulic fluids approved by a specific equipment manufacturer are goods that are regularly in short supply. Deliveries arrive once every month or two, and the entire volume is sorted out within a week. A factory buyer went to your website, saw “Out of stock”, got upset, added it to favorites and switched to other tasks. Three weeks later, the goods arrived at your warehouse, 1C updated the balances, WooCommerce changed the status - and the buyer received the letter before your manager had time to call the customer base. The order is placed in five minutes, the money is in your account, everyone is happy. No manager, no calls, no “when it happens, write down my number.” And if you consider that the notification is sent to all users who have this product in their wish list at the same time, you get a multiplying effect: one delivery of a product can generate ten to twenty orders automatically within an hour.

Brand analogues: how to take away competitors’ traffic

Now let's talk about a feature that few people implement on WooCommerce, but which brings fantastic SEO results at minimal cost - automatic brand analogue pages. The idea is simple and beautiful: if you sell domestic oils and lubricants, but your customers are accustomed to Shell, Mobil, Castrol, Total - you need pages like “Shell oil analogues”, “Mobil lubricant analogues” and so on. These are pages that intercept search traffic for queries like “Russian equivalent of Shell Tellus S4 VX 32”, “how to replace Mobil DTE 25”, “domestic replacement for Castrol Hyspin AWS 32”. These queries exist, thousands of people search for them every month (especially after Western brands left the Russian market), and if you have pages with relevant, structured content, you get this traffic for free.

The BrandAnalogService module works with the WordPress page tree - and this is a fundamental architectural decision. You create a root page “Analogs of oils and lubricants”, under it there are child pages for each brand: “Analogs of Shell oils and lubricants”, “Analogs of Mobil oils and lubricants”, “Analogs of Total oils and lubricants” and so on. Under each brand page there are pages for specific products: “Analog of Shell Tellus S4 VX 32”, “Analog of Shell Omala S4 GX 320”, “Analog of Shell Corena S4 R 46”. Each of these pages is a full-fledged WordPress page with its own URL, meta data, content, and each is indexed by search engines as a separate document. The module automatically scans this tree, parses page titles, extracts the brand name from the title (removing the “Oils and Lubricants Analogs” prefix), and then matches each product page with a real product in WooCommerce.

The matching algorithm is three-step, and I want to explain each step because it is critical to understanding how the module works with your directory. The first step is an exact match on the product name. If the page is called “Shell Tellus S4 VX 32” and there is a product with the same name in WooCommerce - match. But in reality, an exact match is rare, because products in WC usually have longer names: “Hydraulic oil Shell Tellus S4 VX 32 (20 l.).” Therefore, the second step is a substring search: if the extracted name is part of the WC product name, it is considered a match. Moreover, from several matching products, the one whose name is shorter is selected - a more specific match. And finally, the third step is a fuzzy comparison through the similar_text function with a threshold of fifty percent. This is a fallback for cases where the names are slightly different - typos, different transliterations, different word order. The three-step approach provides a high percentage of automatic matching: in our experience, eighty to ninety percent of pages are matched without manual intervention.

After scanning, you receive structured data: for each brand - a list of found products, grouped by WooCommerce categories. Hydraulic oils, transmission oils, industrial oils, greases - each category separately, with the technical characteristics of each product. The data is cached in wp_options via the scan_brand method to avoid querying the database every time the page is opened. Cache update - upon request from the admin panel, the “Rescan” button for each brand separately or for all at once. On the frontend, everything is displayed through the shortcode [wpaic_brand_analogs brand="Shell"] - a stylish carousel of cards with tabs by category. Click the “Hydraulic oils” tab - you see all Shell analogues in this category with key characteristics and links to individual pages of analogues, where you can read a detailed comparison.

Here's why it works for SEO, and why I think analog pages are one of the most effective content marketing tools for e-commerce. Each analog page is a separate URL with unique content, optimized for a specific long-tail search query. “Shell Tellus S4 VX 32 analogue” is a request with the highest commercial intent. The person who enters it into Google already knows what he needs, has already worked with this oil, and is looking for where to buy an analogue - cheaper, faster, without supply problems. This is hot traffic, ready to buy. And if your page contains a table comparing characteristics with the original (viscosity, temperatures, tolerances), a detailed description of the analogue and an “Add to cart” button, you get a conversion many times higher than with standard advertising in Direct. On the project of one oil and lubricant distributor, one hundred and twenty pages of analogues created using this method became a noticeable source of organic traffic and orders within six months.

Separately, I would like to dwell on attribute mapping, because this is the detail that distinguishes the automatic generation of cards from manual work. Different product categories have different key characteristics, and the analogue card should show exactly those that are important for selection. For hydraulic oils, this is viscosity at 40°C and at 100°C, viscosity index, pour point and flash point. For greases - operating temperature range, NLGI class, thickener type, dropping point. For compressor oils - compatibility with refrigerants, ISO viscosity grade. The module allows you to configure attribute mapping by WooCommerce categories: for each category, specify a list of attributes (taxonomies) that will be displayed on analogue cards. If mapping is not configured for a specific category, the module will automatically pull up the first five non-empty product attributes, filtering out the obviously irrelevant ones: “Manufacturer” (why show the manufacturer on a page that already talks about a specific brand?), “Origin” and attributes with URL-encoded slugs, which are usually technical garbage.

Practical advice for those who decide to implement analogue pages: do not try to cover all brands at once. Start with the five to ten key competitive brands that your customers mention most often and are most searched for in your niche. Create a tree of pages, fill them with content - you can do it manually for the most important ones, or you can use our AI content generator for mass creation. Run scanning through the admin panel, make sure that the comparison was completed correctly (the report will show how many pages were successfully linked to products and how many were not linked). After a couple of weeks, check Google Search Console and you will see new pages starting to get impressions for queries that you never caught before. And then gradually expand: new brands, new products. Each new page is another fishing hook in the ocean of search traffic, and the more hooks, the more fish.

Why we built this instead of YITH

I'm sure that right now some of the readers are thinking: “Why reinvent the wheel? There are YITH WooCommerce Wishlist and YITH WooCommerce Compare - proven plugins that have been working for years, thousands of installations.” And this is a fair question, to which I have a detailed answer, based not on theory, but on real experience working with both plugins on several projects.

YITH Wishlist Premium costs $99 per year. YITH Compare Premium - $79 per year. Total $178 annually for two plugins, for two functions. For one site. If you have three stores, multiply by three. Five hundred plus dollars every year. Over five years, that’s almost three thousand dollars. For functions that work out of the box on marketplaces and are considered basic. But you know what? Cost isn't even the main issue. Money can be earned. The main problem is conflicts with the theme, excessive resource consumption, dependence on third-party code and the inability to customize properly.

We worked with a client who had YITH Wishlist Premium on a site with sixteen thousand products and the dt-the7 theme. The plugin stored wishlist data in its own tables, generated its own styles and scripts, and pulled along the YITH Plugin Framework - this is a common PHP framework for all YITH plugins, which connects once, but is noticeably heavy and adds its own hooks to each page. On every page load, wishlist CSS and JS files were loaded, even if there were no products on the page - for example, on the “About the company” or “Contacts” page. The comparison module from YITH opened the table in a separate popup window, which looked terrible in a mobile browser - a small window on top of the page, not adapted to the touch interface, which could not be scrolled properly. Attempts to customize the appearance ran into minified styles with “do not edit” comments and templates, the overriding of which required copying into the theme and manual editing of the PHP code.

When we began designing the replacement within COS WP Woo, we set some fundamental conditions from which we did not deviate. Full backwards compatibility: yith_woocompare_table shortcode, yith_woocompare_list cookie - everything remains the same to make the migration absolutely painless for site visitors. A buyer who added products to comparison via YITH yesterday sees them in our module today - without any action on his part. Automatic import of settings: the migrate_from_yith method reads all YITH Compare options from wp_options and converts them into our format - a set of table fields, comparison page ID, product limit, button text, table title. One click in the admin panel and all settings are transferred. No lost data, no broken pages, no manual reconfiguration.

Performance is a separate important topic. YITH loads its framework and assets globally, on every page of the site. We only load CSS and JS where they are needed. The should_load_assets method in our CompareFrontend checks the current page: is it a WooCommerce catalog, product card, cart, comparison page or shortcode page? If yes, we will load it. If not, we won’t load. For the floating comparison panel, we eventually decided to load the script globally - but this is one minimal JS file weighing several kilobytes, and not an entire framework. The difference in loading speed is noticeable, especially on mobile devices with limited bandwidth and on sites where every millisecond of Page Speed ​​affects search rankings.

And last but not least, a unified ecosystem. YITH Wishlist and YITH Compare are two completely independent plugins that know nothing about each other. The comparison button and the wishlist button live in different plugins, are styled separately, conflict with the theme in different ways, are updated at different times, and sometimes after updating one, the other breaks. In COS WP Woo, all three modules - Compare, Wishlist and Brand Analogs - are part of one plugin, one architecture, one release cycle. They use one translation system, one style approach, one AJAX handler architecture with nonce checking. The comparison and wishlist buttons on the product card are side by side and look like one because they are designed as one. A shortcode of brand analogues can contain compare and add to wishlist buttons, because all modules are aware of each other. This is not a zoo of ten plugins from ten authors, each of which uses its own framework and conflicts with its neighbor - this is one well-thought-out, tested system.

What if we look at all this from the other side? Let's talk about the average check - for the sake of which, in fact, everything is started. I argue that the three features described increase the average check of an online store, and here is my argument for each of them.

Comparison of products pushes the buyer towards a more expensive option. When a person sees two oils side by side in one table - one for two thousand rubles with three technical characteristics, the other for three and a half thousand with seven characteristics, a wider temperature range and approval from the equipment manufacturer - he intuitively understands that the expensive one is better suited for his task. Without a comparison table, he would have chosen the cheap one because he didn’t see the difference and didn’t want to waste time studying the two product cards separately. With a comparison table, he chooses consciously - and often chooses a more expensive and marginal product for you, because now he understands what he is paying for. This is an upsell through information, not through pressure from a manager. And this is the upsell for which the buyer thanks you, rather than gets annoyed.

Wishlist works for the average check through an accumulation mechanism. The buyer adds products to favorites within a week, two weeks, month, quarter. When the moment of purchase comes - be it the arrival of the budget, the end of the reporting period, or simply a notification of a price reduction - he places an order not for one product, but for five, ten, twenty. I saw this in the analytics of several stores: the average order of users who actively use the wishlist is two to three times larger in amount than those who buy impulsively “on the fly.” The logic is simple: if a person collected a list, it means he thought, planned, and prepared a budget. His order is thoughtful and large. A wishlist turns an impulsive buyer who buys one jar of butter into a planning buyer who places an order for the entire line of consumables.

Brand analogues increase the average bill by expanding the visible assortment. A person came from Google looking for an analogue of one specific oil, but saw on your website that you have analogues for a whole line. Shell Tellus S4 VX 32, Shell Tellus S4 ME 46, Shell Omala S4 GX 320, Shell Corena S4 R 46 - and for each there is a Russian analogue with a detailed table of characteristics. The buyer who came for one canister leaves with an order for five. Because he saw that your store is a full-fledged, systematic alternative to imported brands across the entire line, and not a random find from one Google search. You have ceased to be “a site where I accidentally found one analogue” and become “a store where there are analogues of everything I need.” This is a huge difference in perception and order size.

I would like to touch on several technical points that are important for those who will implement these modules on their WooCommerce website. Working with guest users is a fundamental issue for any online store where registration is not required. Compare stores the list in the yith_woocompare_list cookie with a lifetime of thirty days, which covers even the long decision cycle in B2B. The wishlist for guests uses client storage, and upon authorization, it seamlessly merges the accumulated data into the database via INSERT IGNORE. Analogues - completely server-side rendering via shortcode, do not depend on the authentication state at all. This means that an unauthorized visitor can fully use the comparison and add products to favorites without creating an account. Registration becomes necessary only for long-term storage of the wishlist and receiving email notifications - and this is the correct, non-violent incentive for registration: “register so as not to lose your favorites and receive notifications about price reductions,” and not “register to continue using the site.”

AJAX processing deserves special mention because it directly affects the user experience. All actions - adding to comparison, removing from comparison, toggle wishlist - work through wp_ajax and wp_ajax_nopriv with mandatory nonce checking to protect against CSRF attacks. It’s safe and fast: the user clicks a button - the AJAX request goes to the server - the response is returned in fifty to one hundred milliseconds - the interface is updated instantly. No page reloads, no white screens, no lost scroll position. The buyer remains exactly in the place in the catalog where he was and continues to choose. This seems self-evident until you come across plugins that, every time they are added to a wishlist, completely reload the page and kick the customer to the top of the directory. On a mobile device, where a person scrolled through two hundred products, clicked the heart and suddenly found himself at the top - this is a guaranteed loss of conversion and irritation of the user.

Shareable comparison URL is a feature we added based on specific requests from B2B clients. The format is extremely simple: your-site.ru/comparison/?wpaic_compare=123,456,789. A buyer or manager can copy this link and send it to anyone - a friend, colleague, purchasing manager, supervisor, or in a corporate chat. The recipient will open the link and see the same comparison table with the same products, even if he himself has never been to this site and has not added anything. For B2B, this is a standard everyday scenario: a production engineer compared three lubricant options, sent a link to the buyer, the buyer looked, agreed with the chief engineer (sending the same link further) and placed an order. The decision chain is three people, one URL, one table. No registration, no cookies, no repeating characteristics over the phone - a clean URL with a parameter that works the same for everyone.

I sometimes hear from fellow marketers that all these functions - comparisons, wishlists, analogues - are a “nice to have” and not a “must have”. That first you need to set up advertising, SEO, sales funnel, CRM, and only then think about UX improvements. I strongly disagree with this, and here's why. Advertising in Direct brings traffic to the site. SEO brings organic traffic to the site. But if the site does not have tools for an informed, comfortable choice, traffic flows away like water through a sieve. You pay for every click on an ad, for every position in the search results, and the buyer leaves because he can’t properly compare two similar products and choose the right one. Or he forgets about your store after a week because there is no wish list and no notifications that would bring him back. Or he searches for an analogue of imported oil on Google and ends up with a competitor, because you don’t have a page of analogues, but your competitor does.

COS WP Woo covers all three needs with one plugin, one installation, one license. Comparison module with AJAX addition, dynamic attributes, PDF export, shareable URLs and full backwards compatibility with YITH Compare. Wishlist module with multiple lists, three levels of privacy, sharing via a unique link, automatic merging of guest data, drag-and-drop sorting and analytics of the most popular products. Brand analogs module with automatic scanning of the WordPress page tree, a three-stage product matching algorithm, attribute mapping by category and SEO-optimized shortcodes with a carousel and tabs. And on top of all this - automatic email notifications about price reductions and returns in stock, which convert deferred demand into real sales without the participation of a manager, without external services and without monthly payments for the email platform.

If you are currently using YITH Wishlist and YITH Compare, the migration will take five minutes. Deactivate YITH, activate COS WP Woo, click the import settings button - you're done. Shortcodes are compatible, cookies are compatible, no data is lost. If you don’t use comparison, wishlists, or analog pages at all, it’s time to start, because every day without these tools means lost orders, a lower average check and lost SEO traffic on analog queries that your competitors take. And if you need help with setup, with creating a tree of analogue pages, or with non-standard mapping of attributes for your catalog, write to us. We developed this plugin, we know it down to the last line of code, and we are interested in it working on your site as effectively as on our own projects. Try COS WP Woo - and let your average bill finally begin to grow the way you deserve.