Kako uporabiti podatke o izdelkih WooCommerce v avtomatiziranih emailih

Najhitrejši način, da avtomatiziran email deluje osebno, je, da vanj potegnete resnične podatke o izdelku — točno tisti izdelek, ki si ga je nekdo ogledal, njegovo trenutno ceno, ali je spet na zalogi, število kosov ob nizki zalogi, sliko, kategorijo. WooCommerce vse to že hrani, dobra email platforma pa ta polja bere v živo ob pošiljanju. To pomeni, da lahko email za opuščeno košarico prikaže natančen izdelek z današnjo ceno, ne posnetka zaslona iz časa, ko ste gradili predlogo. Ta vodnik govori o tem, kako ta polja izdelkov povezati v svoje avtomatizirane tokove, da je vsak email točen in konkreten. To je drugačna naloga od odločanja, katere izdelke nekomu priporočiti — to je kako samodejno priporočati izdelke WooCommerce po emailu — in od deljenja občinstva, kar je uporaba podatkov o naročilih WooCommerce za segmentacijo emailov.

Takojšen odgovor: dinamični bloki izdelkov, ne ročno sestavljeni

Če avtomatizirane emaile gradite tako, da ročno tipkate imena izdelkov, lepite slike in v predlogo pišete cene, nehajte. Ta pristop se zlomi v trenutku, ko se spremeni cena, izdelek pošteje ali tok teče za stranko, ki si je ogledala nekaj povsem drugega.

Namesto tega uporabite dinamične bloke, ki se sklicujejo na podatke o izdelku prek ID-ja ali prek sprožilnega dogodka. Email pravi “prikaži izdelek, ki si ga je ta stranka ogledala, z njegovo živo ceno in sliko”. Ob pošiljanju platforma prebere WooCommerce in to izpolni. Ena predloga, pravilna za tisoče različnih strank, in samoposodabljajoča, ko se vaš katalog spremeni.

Prava težava: emaili, ki ob prihodu že lažejo

Tukaj je situacija, v katero se ujame skoraj vsaka trgovina. Zgradite lep email za opuščeno brskanje s trdo vpisanim glavnim izdelkom. Teden dni deluje. Nato ta izdelek poide, ali pa mu za akcijo spustite ceno, ali ga ukinete. Email se še naprej pošilja — zdaj ljudi usmerja na razprodan izdelek po lanski ceni.

Nekaj časa nihče ne opazi, ker tok ne javi napake. Le tiho pošilja pokvarjena sporočila. Stranka klikne, pristane na strani z razprodanim izdelkom ali vidi drugačno ceno od tiste, ki jo je email obljubil, in odide. Za ta obisk ste plačali dvakrat in ga izgubili zaradi neujemanja podatkov.

Zakaj “kar posodabljaj predloge” ni rešitev

Očiten odgovor je, da predloge ročno vzdržujete posodobljene. V trgovini s petdesetimi SKU-ji in lastnikom, ki ima čas, morda. V pravem katalogu s stotinami izdelkov, tedenskimi spremembami cen in zalogo, ki se premika dnevno, so ročne posodobitve izgubljena igra. Vedno boste zaostajali, in emaili, ki najbolj štejejo — avtomatizirani, ki tečejo 24 ur na dan brez vašega nadzora — so prav tisti, ki najprej zastarijo.

Strukturna rešitev je, da podatkov o izdelku sploh nehate hraniti v emailu. Shranite sklic. Naj email vsakič ob pošiljanju potegne trenutne podatke. Tako je sprememba cene v WooCommerce samodejno sprememba cene v vsakem prihodnjem emailu, brez urejanja predloge.

Kje izteka prihodek: vrzel med emailom in stranjo izdelka

Iztekanje je razkorak med tem, kar prikazuje email, in tem, kar prikazuje pristajalna stran. Vsako neujemanje je majhna izdaja zaupanja in izgubljen klik.

Preprost ponazoritveni primer: tok za opuščeno brskanje pošlje 500 emailov na mesec, ki kažejo na izdelek, ki je zdaj razprodan. Recimo, da jih 30 % odpre in 8 % teh klikne — to je 12 ljudi na mesec, ki pristanejo na mrtvi strani, vsak od njih topel obiskovalec z veliko namere, ki ste ga že prislužili. Pomnožite to čez več zastarelih tokov in nabere se resničnih naročil. Živi podatki o izdelku to vrzel zaprejo: razprodan izdelek se lahko samodejno skrije ali zamenja, cena, ki jo stranka vidi v predalu, pa ustreza tisti ob nakupu.

Praktična rešitev: katera polja izdelkov uporabiti in kje

Ne sodi vsako polje v vsak email. Podatke uskladite z nalogo toka.

Ime izdelka, slika, cena in URL — osnovna četverica. Uporabite jih v vsakem toku, ki se sklicuje na določen izdelek: opuščena košarica, opuščeno brskanje, ponovno na zalogi. Vedno jih potegnite v živo.

Status zaloge in količina zaloge. Dve močni uporabi. Prvič, skrijte ali zamenjajte izdelke, ki so razprodani, da nikoli ne promovirate mrtvega izdelka. Drugič, pristna nuja: “le še 3 na voljo” je poštena in učinkovita takrat, ko je resnična in prebrana iz živih podatkov — nikoli je ne ponarejajte. Če izvajate tok za opuščeno brskanje v WooCommerce, vas prav živ status zaloge obvaruje pred sramoto.

Kategorija in atributi izdelka (velikost, barva, material, znamka). Uporabni za filtriranje in za to, da je besedilo konkretno. Email, ki pravi “mornarsko modri par v vaši velikosti”, se bere povsem drugače kot “izdelek, ki ste si ga ogledali”.

Akcijska cena proti redni ceni. Če gre ogledan izdelek v akcijo, se avtomatiziran email “cena je padla pri nečem, kar ste si ogledali” napiše sam — in pretvarja, ker je sprožilec resnična vrednost, ne izmišljena promocija.

Časovnica ponovne oskrbe ni ravno polje izdelka, je pa podatkovno gnana na enak način: pri potrošnem blagu vam izdelek in datum nakupa stranke povesta, kdaj ji bo pošlo. Ta logika živi v kako zgraditi tok za ponovno oskrbo v WooCommerce.

Kaj avtomatizirati: trije tokovi, ki živijo na podatkih o izdelkih

Za vsakega izpišite sprožilec, podatke in cilj.

  • Opuščeno brskanje. Sprožilec: ogledal si je izdelek, ni ga dodal v košarico, odšel. Uporabljeni podatki: ime, slika, živa cena, status zaloge ogledanega izdelka. Cilj: pripeljati ga nazaj na točno tisto stran. Zamenjajte izdelek, če je bil medtem razprodan.
  • Ponovno na zalogi. Sprožilec: izdelek, ki ga je stranka želela, se vrne na zalogo. Uporabljeni podatki: preobrat statusa zaloge, podrobnosti izdelka, zapis o zanimanju stranke. Cilj: naročilo pred vsemi drugimi, preden se spet razproda.
  • Opozorilo o padcu cene. Sprožilec: akcijska cena postavljena na izdelku, ki si ga je stranka ogledala ali ga želela. Uporabljeni podatki: redna proti akcijski ceni. Cilj: pretvoriti obstoječo namero z resnično novico, ne s popustom, ki ste ga izmislili.

V vsakem primeru personalizacijo opravljajo podatki o izdelku — ne pišete besedila po meri za vsako stranko, ampak pustite, da živa polja izpolnijo pametno predlogo.

Primer iz trgovine (ponazoritveno)

Recimo, da prodajate opremo za kavo. Stranka si ogleda mlinček za espresso za 120 €, ne kupi in odide. Vaš email za opuščeno brskanje sproži naslednje jutro, prikaže točno tisti mlinček, njegovo živo ceno, njegovo sliko in “na zalogi”. Dva dni kasneje ga za vikend akcijo znižate na 99 €. Stranka, ki si ga je ogledala, a še okleva, dobi email o padcu cene, ki samodejno prebere novo akcijsko ceno — “mlinček, ki ste si ga ogledali, je ta vikend cenejši za 21 €”. Nihče ni znova sestavljal predloge. Sporočilo je gnala sprememba kataloga. (Ponazoritvene številke — uporabite svoje.)

Če imate velik katalog, se isto načelo obnese, a potrebuje varovala, da tokovi ne promovirajo linij s tanko maržo ali večno razprodanih; to je področje članka gradnja avtomatizacij WooCommerce za velik katalog izdelkov.

Kako izmeriti, ali deluje

  • Stopnja klikov na bloke izdelkov — živi, relevantni izdelki naj bi premagali statične glavne slike.
  • Odboj po kliku / zadetki na mrtvih straneh. Če ljudje kliknejo in takoj odidejo, vaši emaili morda še vedno kažejo na zastarele ali razprodane izdelke. To bi se moralo približati ničli, ko so podatki v živo.
  • Prihodek na email iz tokov, gnanih z izdelki, proti vašim splošnim kampanjam.
  • Stopnji pretvorbe pri ponovno na zalogi in padcu cene posebej — te so ponavadi med najbolje pretvarjajočimi emaili, ki jih trgovina pošlje, ker namera že obstaja.

Kako pomaga Omnisend

Razlog, da v svojih trgovinah uporabljam Omnisend, je, da njegova povezava z WooCommerce bere podatke o izdelku v živo — ime, sliko, ceno, zalogo, kategorijo — tako da dinamični bloki ostanejo točni, ne da bi jaz pestoval predloge. Email za opuščeno brskanje nastavite enkrat, se sklicujete na ogledan izdelek, in ta se pravilno izriše za vsako stranko ter se posodobi sam, ko se katalog spremeni. Bloki za izbiro izdelkov omogočajo, da izdelke vstavite po ID-ju ali po pravilu, živ status zaloge pa lahko razprodane izdelke samodejno skrije.

Poštena omejitev: orodje odraža le tisto, kar mu WooCommerce pošlje. Če je vaša sinhronizacija nepopolna ali slike in cene izdelkov že v WooCommerce niso čiste, emaili podedujejo te vrzeli — točni podatki na vhodu so bistvo vsega. Omnisend je partner Shopimation prek partnerskega programa; priporočam ga iz vsakodnevne uporabe, brezplačni paket pa zadošča, da zgradite en tok, gnan z izdelki, in potrdite, da se polja pravilno izrišejo, preden razširite.

Vaš naslednji korak

Izberite svoj najbolj uporabljen avtomatiziran tok — običajno opuščena košarica ali opuščeno brskanje — in preverite vsak sklic na izdelek v njem. Je cena živa? Skrije razprodane izdelke? Če je katerokoli polje trdo vpisano, ga danes zamenjajte z dinamičnim sklicem. Ko vaši emaili prikazujejo prave podatke, je naslednje vprašanje prikazovanje pravih izdelkov vsaki osebi: kako samodejno priporočati izdelke WooCommerce po emailu.

How to Use WooCommerce Product Data in Automated Emails

The fastest way to make an automated email feel personal is to pull real product data into it — the exact item someone viewed, its current price, whether it’s back in stock, the low-stock count, the image, the category. WooCommerce already stores all of it, and a good email platform reads those fields live at send time. That means an abandoned-cart email can show the precise product with today’s price, not a screenshot from when you built the template. This guide is about wiring those product fields into your automated flows so each email is accurate and specific. It’s a different job from deciding which products to recommend to someone — that’s how to recommend WooCommerce products automatically by email — and from splitting your audience, which is using WooCommerce order data for email segmentation.

The immediate answer: dynamic product blocks, not hand-built ones

If you’re building automated emails by manually typing product names, pasting images, and writing prices into the template, stop. That approach breaks the moment a price changes, an item sells out, or the flow runs for a customer who looked at something else entirely.

Instead, use dynamic blocks that reference product data by ID or by the trigger event. The email says “show the product this customer viewed, with its live price and image.” At send time the platform reads WooCommerce and fills it in. One template, correct for thousands of different customers, and self-updating when your catalog changes.

The real problem: emails that lie by the time they arrive

Here’s the situation almost every store hits. You build a beautiful browse-abandonment email with a hero product hard-coded in. It works for a week. Then that product goes out of stock, or you drop the price for a sale, or you discontinue it. The email keeps sending — now pointing people at a sold-out item at last month’s price.

Nobody notices for a while, because the flow doesn’t error. It just quietly sends broken messages. The customer clicks, lands on an out-of-stock page or sees a different price than the email promised, and leaves. You paid to acquire that visit twice and lost it to a data mismatch.

Why “just update the templates” isn’t the fix

The obvious answer is to keep templates current by hand. In a store with fifty SKUs and a founder who has time, maybe. In a real catalog with hundreds of products, weekly price changes, and stock that moves daily, manual updates are a losing game. You will always be behind, and the emails that matter most — the automated ones running 24/7 without you watching — are exactly the ones that go stale first.

The structural fix is to stop storing product details in the email at all. Store a reference. Let the email pull the current data every time it sends. Then a price change in WooCommerce is automatically a price change in every future email, with no template edit.

Where revenue leaks: the gap between the email and the product page

The leak is the disconnect between what the email shows and what the landing page shows. Every mismatch is a small betrayal of trust and a lost click.

A simple illustrative example: a browse-abandonment flow sends 500 emails a month pointing at a product that’s now out of stock. Say 30% open and 8% of those click — that’s 12 people landing on a dead page monthly, each one a warm, high-intent visitor you’d already earned. Multiply across several stale flows and it adds up to real orders. Live product data closes that gap: an out-of-stock item can be hidden or swapped automatically, and the price the customer sees in the inbox matches the one at checkout.

The practical solution: which product fields to use, and where

Not every field belongs in every email. Match the data to the flow’s job.

Product name, image, price, and URL — the core four. Use them in any flow that references a specific item: abandoned cart, browse abandonment, back-in-stock. Always pull them live.

Stock status and stock quantity. Two strong uses. First, hide or swap products that have sold out so you never promote a dead item. Second, genuine urgency: “only 3 left” is honest and effective when it’s true and read from live data — never fake it. If you’re running a WooCommerce browse-abandonment flow, live stock status is what keeps it from embarrassing you.

Category and product attributes (size, color, material, brand). Useful for filtering and for making copy specific. An email that says “the navy pair in your size” reads completely differently from “the item you viewed.”

Sale price vs. regular price. If a viewed product goes on sale, an automated “the price dropped on something you looked at” email writes itself — and it converts, because the trigger is real value, not a manufactured promo.

Replenishment timing isn’t a product field exactly, but it’s data-driven the same way: for consumables, the product plus the customer’s purchase date tells you when they’ll run low. That logic lives in how to build a WooCommerce replenishment flow.

What to automate: three flows that live on product data

Spell out the trigger, the data, and the goal for each.

  • Browse abandonment. Trigger: viewed a product, didn’t add to cart, left. Data used: viewed product’s name, image, live price, stock status. Goal: bring them back to that exact page. Swap the product out if it’s since sold out.
  • Back-in-stock. Trigger: a product the customer wanted returns to stock. Data used: stock status flip, product details, the customer’s interest record. Goal: first-mover order before it sells out again.
  • Price-drop alert. Trigger: sale price set on a product a customer viewed or wanted. Data used: regular vs. sale price. Goal: convert existing intent with real news, not a discount you invented.

In each case, the product data is doing the personalization — you’re not writing custom copy per customer, you’re letting live fields fill a smart template.

A store example (illustrative)

Say you sell coffee gear. A customer views a €120 espresso grinder, doesn’t buy, and leaves. Your browse-abandonment email fires the next morning showing that exact grinder, its live price, its image, and “in stock.” Two days later you cut it to €99 for a weekend sale. A customer who viewed it but is still on the fence gets a price-drop email reading the new sale price automatically — “the grinder you looked at is €21 off this weekend.” No one rebuilt a template. The catalog change drove the message. (Illustrative figures — use your own.)

If you run a big catalog, the same principle scales but needs guardrails so flows don’t promote thin-margin or perpetually-out-of-stock lines; that’s the territory of building WooCommerce automations for a large product catalog.

How to measure whether it’s working

  • Click-through rate on product blocks — live, relevant products should beat static hero images.
  • Post-click bounce / dead-page hits. If people click and immediately leave, your emails may still be pointing at stale or out-of-stock items. This should approach zero once data is live.
  • Revenue per email from product-driven flows vs. your generic campaigns.
  • Back-in-stock and price-drop conversion rates specifically — these tend to be among the highest-converting emails a store sends, because the intent already exists.

How Omnisend helps

The reason I use Omnisend in my own stores is that its WooCommerce connection reads product data live — name, image, price, stock, category — so the dynamic blocks stay accurate without me babysitting templates. Set up a browse-abandonment email once, reference the viewed product, and it renders correctly for every customer and updates itself when the catalog changes. Product-picker blocks let you drop in items by ID or by rule, and live stock status can hide sold-out products automatically.

The honest limit: the tool only reflects what WooCommerce sends it. If your sync is incomplete, or product images and prices aren’t clean in WooCommerce to begin with, the emails inherit those gaps — accurate data in is the whole game. Omnisend is an affiliate partner of Shopimation; I recommend it from daily use, and the free tier is enough to build one product-driven flow and confirm the fields render correctly before you scale.

Your next step

Pick your most-used automated flow — usually abandoned cart or browse abandonment — and check every product reference in it. Is the price live? Does it hide sold-out items? If any field is hard-coded, swap it for a dynamic reference today. Once your emails show the right data, the next question is showing the right products to each person: how to recommend WooCommerce products automatically by email.

Leave a Reply

Your email address will not be published. Required fields are marked *