Hogyan gyűjtsünk termék-visszajelzéseket és funkciókéréseket a Redditről, az X-ről és a Hacker News-ról

Miért maradnak le a hagyományos visszajelzési csatornák

A legtöbb csapat három forrásból gyűjt visszajelzéseket: támogatási jegyekből, alkalmazáson belüli widgetből és értékesítési hívásokból. Mindháromnak ugyanaz a torzítása: csak azoktól kapnak hírt, akik már eleve beszélnek veled.

A nyilvános fórumszálak egészen mások. Valaki, aki múlt hónapban mondta le az előfizetését, nem fogja kitölteni a kérdőívedet, de a Redditen szívesen elmagyarázza, miért távozott. Egy érdeklődő, aki eszközöket hasonlít össze, egy „melyiket válasszam?” bejegyzésben felsorolja, mi hiányzik a te megoldásodból. Ez olyan visszajelzés, amelyet semmilyen más módon nem kapnál meg, és gyakran más felhasználók egyetértő vagy vitató válaszai kísérik, ami megmutatja, mennyire elterjedt a probléma.

A csapda a mennyiségben rejlik. Ha hetente egyszer rákeresel a terméked nevére, találsz néhány szálat, általában már túl későn a válaszadáshoz. Ha nyers riasztást állítasz be a nevedre, minden egyes említést megkapsz, beleértve azokat is, amelyeknek semmi közük a termékhez. A trükk az, hogy olyan riasztásokat hozz létre, amelyek kifejezetten a visszajelzéseket keresik.

Visszajelzésekre vadászó riasztások beállítása

A KWatch riasztás a listáján szereplő összes kulcsszóra egyezést keres, így a vesszők logikai ÉS (AND) kapcsolatként működnek. Ez teszi működőképessé a visszajelzés-riasztásokat. A terméked nevére vonatkozó egyetlen általános riasztás helyett a nevet olyan szavakkal párosítod, amelyeket az emberek akkor használnak, amikor változtatást szeretnének.

Íme egy kiinduló készlet, ahol az „acme” a terméked nevét jelöli:

1. acme, wish és acme, would be nice funkciókérésekhez
2. acme, bug és acme, broken hibajelentésekhez
3. acme, switched és acme, cancelled lemorzsolódási okokhoz
4. acme, missing és acme, doesn't support a kipróbálás során felmerülő hiányosságokhoz

Minden sor egy külön riasztás, mert egy olyan riasztáshoz, amely az összes ilyen szót tartalmazza, mindegyiknek szerepelnie kellene ugyanabban a bejegyzésben. Valószínűleg egy hét után finomítani fogod a megfogalmazást, amint látod, hogyan beszélnek a saját felhasználóid. Az emberek ritkán írják le a „feature request” kifejezést, ezért keresd azokat a fordulatokat, amelyeket valóban használnak, mint például a „nagyszerű lenne, ha”.

Néhány szűrő elvégzi a felesleg nagy részének kiszűrését. A Redditen és a Hacker News felületén kapcsold be a Csak teljes szavak (Whole Words Only) funkciót, ha a terméked neve rövid vagy gyakori, így az „acme” nem fog egyezni az „acmeplex” kifejezéssel. Add hozzá a saját csapatod fiókjait a Kizárt felhasználók (Excluded Users) listájához, hogy a válaszaid és bejelentéseid ne váltsanak ki riasztásokat. Ha van termék-subreddited, létrehozhatsz egy arra korlátozott külön riasztást a Belefoglalt subredditek (Included Subreddits) segítségével, és teljesen elhagyhatod a második kulcsszót, hiszen szinte minden ott közzétett bejegyzés eleve visszajelzés.

A kizárt kulcsszavak a belefoglaltakkal ellentétesen működnek. A megadott kulcsszavak mindegyikének egyeznie kell, de a bejegyzés azonnal kiesik, amint a kizárt kulcsszavak bármelyike megjelenik. Tartsd ezt a listát röviden és célzottan, különben a valódi visszajelzéseket is kiszűröd a zajjal együtt. A kulcsszavas riasztások zajának csökkentéséről szóló cikkünk részletesebben bemutatja az összes szűrőt.

Hol érdemes először fülelni

Nem minden platform nyújt azonos típusú visszajelzést. Úgy látom, hogy a Reddit és a Hacker News az a hely, ahol az emberek hosszú, részletes panaszokat fogalmaznak meg. Az X rövidebb és indulatosabb, ami hasznos egy hibás kiadás gyors felismerésére. A Linkedin leginkább dicséretekből és bejelentésekből áll, így hátrébb áll a listán, hacsak nem olyanoknak értékesítesz, akik ott rendszeresen írnak az általuk használt eszközökről.

A sebesség platformonként is eltérő, és meghatározza az egyes riasztások felhasználási módját. Íme a frissítési gyakoriságok a dokumentációnkból:

Visszajelzések gyűjtéséhez ezek közül egyik sem lassú. A táblázat azt mutatja, hogy egy Hacker News szál még akkor eljuthat hozzád, amikor a címlapon van – márpedig ez az a pillanat, amikor a csapat egyik tagjának válasza a legnagyobb súllyal bír.

Eljuttatás a termékcsapathoz

Egy olyan riasztás, amelyet senki sem olvas, nem több egy kényelmesebb keresésnél. A csapatok általában azt a lépést hagyják ki, hogy eldöntsék: hova érkezzenek a visszajelzések, és ki lássa azokat.

A legegyszerűbb megoldás egy dedikált Slack-csatorna. A KWatch lehetővé teszi, hogy riasztásonként külön Slack webhookot állíts be, és ez a riasztásonkénti webhook felülírja a fiókszintű beállítást. Így az értékesítési riasztások továbbra is az értékesítési csatornára érkezhetnek, míg a visszajelzés-riasztások mondjuk a #product-feedback csatornára mennek. Azok a termékmenedzserek és mérnökök, akiknek csak olvasniuk kell a bejegyzéseket, Reader szerepkörrel csatlakozhatnak a KWatch csapatodhoz: ez a szerepkör megkapja az értesítéseket, de nem tud riasztásokat létrehozni vagy törölni.

Ha idővel számszerűsíteni szeretnéd a kéréseket, küldd ugyanezeket a riasztásokat inkább egy API webhookra. Minden találat JSON adatcsomagként érkezik. Íme a példa a dokumentációnkból:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

Irányítsd ezt egy Zapier vagy n8n webhookra, és fűzz hozzá egy sort egy táblázathoz, mezőnként egy oszloppal. A query mező megmutatja, melyik riasztás aktiválódott, így a funkciókérések és a hibajelentések maguktól szétválogatódnak. A sentiment mező (pozitív, negatív vagy semleges) gyors lehetőséget ad arra, hogy először a dühös bejegyzéseket emeld ki. Részletesen leírtuk a Zapier és n8n beállítását lépésről lépésre, ha korábban még nem kapcsoltál össze ilyet.

Az e-mail riasztások is működnek, de a hosszú bejegyzések csonkulnak az e-mailben. A funkciókérések általában hosszabbak, így ide a Slack vagy egy webhook sokkal jobban illik.

Mit tegyél a talált információkkal

Amint elkezdenek beáramlani a visszajelzések, nagy a kísértés, hogy mindenre válaszolj. Én kissé visszafognám magam. Egy rövid, hasznos válasz valakitől, aki egyértelműen a terméken dolgozik („ez szerepel az ütemtervünkben, addig is itt van egy áthidaló megoldás”), sokat ér. Ezzel szemben az olyan válaszok sora, amelyek mind regisztrációs linkkel végződnek, lepontozást, egyes subredditeken pedig kitiltást von maga után.

A sokkal értékesebb szokás a heti áttekintés. Hetente egyszer a termékcsapat egyik tagja átnézi a csatornát vagy a táblázatot, és felcímkéz minden tételt: kérés, hiba, lemorzsolódási ok vagy nem releváns. Egy hónap elteltével durva képet kapsz arról, mit kérnek az emberek nyilvánosan, szemben azzal, amit a támogatási jegyekben kérnek. Amikor a két lista eltér egymástól, általában az a legérdekesebb rész.

Ha a leghasznosabb visszajelzések némelyike kulcsszavak helyett egy maroknyi ismert személytől (kiemelt felhasználóktól, elemzőktől, egy versenytárs alapítójától) érkezik, testvértermékünk, a MultiFollow figyeli a konkrét Linkedin- és X-fiókokat, és értesítést küld, amikor közzétesznek valamit, ami nagyszerűen kiegészíti a kulcsszavas riasztásokat.