Prodantix

Ginawa ang Prodantix para sa mga taong gumagawa ng software. Palaging tatlong tanong ang inuulit ng bawat product team: ano talaga ang ginagawa ng mga tao sa loob ng app namin, sino ang dapat makakita ng aling bahagi, at kailan ang tamang sandali para may sabihin sa kanila.

Karamihan ng kumpanya ay bumibili ng magkaibang tool para sa bawat isa sa mga trabahong iyon, at doon nagsisimula ang gulo. Ang bawat tool ay may sarili nitong hiwalay na tala kung sino ang inyong mga user, at unti-unting naglalayo ang mga talang iyon. Akala ng isang tool tapos na ang customer sa pag-set up ng account niya. Hindi pa nakakahabol ang isa, kaya ipinadadala nito sa kanya ang mga tagubilin para sa hakbang na natapos niya noong isang linggo. Walang nakakapansin hangga't hindi siya nagrereklamo, o hangga't hindi nagpapakita ng magkaibang numero ang dalawang dashboard.

Paano binuo ang engine

Apat na primitive ang bumubuo sa engine, at lahat ng iba pa ay nakapatong sa mga ito. Mainam silang sundan nang sunod-sunod, dahil ang bawat isa ay pumapasok sa susunod. Buong-buong tinatalakay sila sa sanggunian ng mga konsepto.

Event

Isang bagay na ginawa ng user, nakuha habang nangyayari: natapos na sign-up, binuksang pahina, iniwang form sa kalagitnaan. Ang mga event ang hilaw na senyas, at sila lang ang pumapasok sa sistema mula sa labas. Lahat ng iba pa ay hinahango mula sa kanila.

User state

Isang buhay at ma-query na projection ng lahat ng nalalaman tungkol sa isang user, hinango mula sa kanyang mga event at ina-update sa sandaling may dumating na bago. Ito ang pinagmumulan ng katotohanang binabasa ng analytics, feature flags at messaging. Hindi ito pang-gabing rollup, at hindi rin kopyang may job na nagpapapareho. Iisa lang ito.

Desisyon

Isang panuntunang sinusuri laban sa user state: sino ang kabilang sa isang cohort, sino ang nakakakuha ng flag, sino ang kwalipikado sa isang mensahe. Dahil binabasa ng desisyon ang buhay na state sa mismong sandaling itinatanong, hindi ito makasasagot mula sa lumang larawan.

Aksyon

Ang ginagawa ng engine kapag pumutok ang isang desisyon: magbukas ng tampok, magpadala ng mensahe, magsimula ng workflow. Ang aksyon mismo ay naitatala bilang isang event, at iyon ang nagsasara ng siklo: ang ginawa ng engine ay nagiging bahagi ng nalalaman nito.

Ang analytics ay pagbabasa ng state

Ang analytics sa Prodantix ay hindi hiwalay na imbakang may sariling kopya ng inyong mga user. Direktang pagbabasa ito ng user state. Ang mga funnel, retention at cohort ay mga query sa parehong buhay na projection na pinapatakbuhan ng iba pang bahagi ng engine, kaya walang SQL na bumabalik-balik sa warehouse at walang hinihintay na pang-gabing rollup: hugis na ng tanong ang state. Ang mga cohort dito ay first-class na bagay: may pangalan, tinutukoy ng mga clause, at napapanahon ang membership habang may nagiging kwalipikado at humihinto.

Pag-iimbak ng tanong na muli ninyong itatanong

Ang dashboard ay isang pinangalanang hanay ng mga tile, at ang tile ay isang query na napatakbo na ninyo kasama ang gusto ninyong hugis ng pagguhit nito. Iniimbak ang query nang eksakto sa pagkakapadala nito ng explorer, kaya hawak ng tile ang tanong at hindi ang larawan ng sagot: ang pagbubukas nito ay nagpapatakbong muli ng query at ibinabalik kayo sa explorer sa mismong query na iyon, malaya kayong igalaw ang saklaw o palitan ang paghahati. Kaya hindi kailanman lumang export ang isang dashboard. Isa itong hanay ng mga tanong na sinasagot ng engine mula sa buhay na state sa tuwing titingin kayo.

Kapag kusang gumalaw ang isang numero

Walang sinumang nakabantay sa bawat tsart. Ginagawa ng Prodantix ang bahaging pagbabantay: binabasa nito ang isang serye nang bawat batch, tinutuos ang baseline at ang lawak ng pagkakalat ng seryeng iyon, at minamarkahan ang mga batch na masyadong malayo rito, sa alinmang direksyon. Iniuulat kapwa ang paglagpak at ang biglang pagsipa, bawat isa ay may kasamang baseline na nilisan nito at kung gaano kalayo ito napunta, kaya matutukoy ninyo ang tunay na pagkabali laban sa karaniwang ingay. Setting ang sensitivity at hindi isang nakapirming tuntunin, at tumatanggi ang detektor na manghula: ang seryeng halos patag, o masyado pang maikli para magkaroon ng hugis, ay walang ibinubungang anuman sa halip na maling alarma.

Ang mga taong tinutukoy ng state

Isang proyeksyon ang user state, at ang people directory ang lugar kung saan ninyo ito binabasa nang isang tao sa bawat pagkakataon. Inililista ng console ang lahat ng nakita ng proyekto, nauuna ang pinakabagong aktibo, may search box at listahang patuloy na naglo-load habang bumababa kayo. Dala ng bawat hilera ang naipon ng engine tungkol sa taong iyon: ilang event, ilang magkakaibang session, kailan siya unang at huling nakita, ano ang huli niyang ginawa, saang mga grupo siya kabilang, at ang mga nakalaang trait (pangalan, email, telepono, avatar) na inilabas sa sarili nilang mga kolum. Ipinapakita ng pagbubukas ng hilera ang buong talahanayan ng mga property, na naglalaman ng anumang inilagay doon ng inyong mga event, hindi ng nakatakdang hanay ng mga field. May sariling tab at sariling mga property ang mga grupo, dahil ang isang kompanya o workspace ay bagay na nakatayo sa sarili nito at sa kanya ang mga bagay na totoo tungkol dito, hindi sa bawat miyembro.

Iisang tao, iba-ibang id

Dumarating ang bisita bago pa ninyo malaman kung sino siya. Binibigyan siya ng SDK ng id, nagbabasa siya ng tatlong pahina, at saka pa lamang siya nagsa-sign up. Hangga’t walang nagsasabi sa engine kung sino siya, walang pangalan ang profile, at iyon mismo ang sinasabi ng directory sa halip na manghula. Kapag naganap ang sign up, iniuugnay ang mga id sa isang tanikalang tumutungo sa iisang kanonikal na pagkakakilanlan, kaya ang anonimong bakas ay pumapasok sa pinangalanang account sa halip na magbukas ng pangalawang profile. Ipinapakita ng bawat hilera kung ilang id ang tumutungo rito, at inililista ang mga ito ng profile. Kung saan hindi kayang tiyakin ng engine mismo, maaari ninyong pagdugtungin nang manu-mano ang dalawang profile: kayo ang pumipili kung aling pagkakakilanlan ang mananatili, ang mga property nito ang nananaig sa banggaan, at nagsasama-sama ang mga bilang. Hindi na iyon muling naghihiwalay. Nananatili sa audit trail ang profile gaya ng pagkakabasa nito bago ang pagsasama, kaya nababawi kung ano ang sinabi nito, ngunit hindi na mapaghihiwalay ang dalawang tao kapag naipagdugtong na.

Panonoorin ang isang session mula simula

Sinasabi sa inyo ng analytics na labing-isang tao ang tumigil sa gitna ng parehong form kahapon. Hindi nito masasabi kung bakit. Itinatala ng session replay ang mismong pahina: kinukuha ng browser SDK ang dokumento at bawat pagbabagong nagaganap dito habang gumagawa ang tao, tinitipon ang mga pagbabagong iyon sa mga nakahanay na chunk at ipinapadala sa recorder, at ipinapatugtog ng console ang session gaya ng pagkakangyari nito. Nakalagay ang bawat recording sa ilalim ng parehong distinct id na ginagamit ng natitirang bahagi ng engine, kaya ang isang session ay sa taong kaya na ninyong hanapin, hindi sa visitor id na umiiral lamang sa loob ng ibang tool.

Ano ang pinapayagang itago ng isang recording

Nakabukas na ang pagtatakip bago pa kayo mag-configure ng anuman. Bawat karakter na tinipa sa isang field ay pinapalitan ng asterisk sa loob ng browser, bago pa ma-upload ang chunk, kaya ang narating ng recorder ay hindi kailanman naglaman ng nilalaman: nananatili ang haba at ang hangganan ng mga salita, kaya mukha pa ring pahina ang replay, at wala na ang mga salita mismo. Tinatakpan ang mga field ng password, email at telepono nakabukas man o nakasara ang pagtatakip, kaya hindi maibubunyag ng pagsara nito ang isang field ng kredensyal. Nananatili ang nakikitang teksto ng pahina maliban kung hihilingin ninyong takpan din iyon. Itinatala ng bawat chunk kung natakpan ito at minamarkahan ng console ang session nang naaayon, kaya alam ninyo palagi kung alin sa dalawa ang pinapanood ninyo. Nasa pribadong imbakan ang mga recording: humihingi ang console ng panandaliang nilagdaang link nang isang chunk sa bawat pagkakataon, at walang maaabot kung wala iyon. Kung gaano katagal mananatiling available ang isang session pagkatapos ay nakatakda sa inyong plano.

Iba-ibang bagay sa iba-ibang tao

Madalas gustong ilabas ng mga koponan ang bago sa iilang user muna at tingnan kung kumusta bago ito makuha ng lahat. Ipinapasya ng Prodantix kung sino ang nakakakita ng ano sa pamamagitan ng pagsusuri ng mga kondisyon laban sa user state: isang attribute, isang operator at isang halaga, sinusuri sa mismong sandaling itanong ang flag at hindi hinahanap sa nakaimbak na listahan. Puwede ninyong ibigay ang bagong tampok sa dalawang porsiyento ng customer, tingnan kung paano nila ito ginagamit, saka palawakin o bawiin nang hindi naghihintay ng panibagong release.

Mga mensaheng dumarating habang nakakatulong pa

Sulit lang ipadala ang isang mensahe habang nakakatulong pa ito. Kayang ipadala ito ng Prodantix sa mismong sandaling may ginawa ang isang tao, o hindi nagawa. Kung naabot ng customer ang hangganan ng plano niya, malalaman niya agad, hindi kinabukasan kung kailan sumuko na siya at lumipat sa iba.

Kapag sumagot sila

Iisang direksyon ang mensahe hanggang may sumagot, at pagkatapos ay isa na itong support thread. Dala rin ng Prodantix ang mga iyon, at ang AI sa loob nila ay nagdadraft, hindi nagpapadala. Ang ibinibigay sa modelo ay ang thread at ang sariling state ng taong iyon, wala nang iba: hindi ang usapan ng ibang kostumer, hindi ang iba pang bahagi ng proyekto ninyo. Sumusulat ito ng iminumungkahing sagot, at nagiging bahagi lamang ng thread ang sagot kapag pinindot ng inyong ahente ang send, kaya ang “imungkahi, huwag ipadala” ay kung paano itinayo ang code at hindi isang tuntuning kailangang tandaan ng isang tao. May sariling kredensyal din ang thread. Ang project key ay tumutukoy sa isang proyekto at naglalakbay sa loob ng bawat pahinang naglalagay ng SDK, kaya hindi ito maaaring kumatawan sa isang tao; may sariling token ang bawat usapan, nakalaan sa iisang thread na iyon, at hindi kailanman ang id sa katawan ng request ang nagpapasya kung sino ang kausap ninyo. Ang pagbubukas ng usapan ang tanging ruta na walang kailangan kundi ang pampublikong susi, kaya ito ay may hangganan sa dami bawat proyekto at bawat tumatawag.

Kayo mismo ang nag-uugnay ng pagkakasunod-sunod

May mga tugong higit sa isang hakbang, at gusto ninyong kayo mismo ang maglatag ng mga ito. Ang workflow ay isang maliit na graph: nagsisimula ito nang manu-mano, o kapag may pumasok o lumabas sa isang cohort, at mula roon ay dumadaan ito sa mga node. May ginagawa ang action node (magsulat ng linya sa log, tumawag sa webhook ninyo). Naghihintay ang delay node, hanggang tatlumpung araw. Humihinto ang wait node hanggang dumating ang isang pinangalanang senyas, may sarili itong labasan kung hindi dumating ang senyas. Sinusubok ng branch node ang mga kondisyon laban sa user state at kinukuha ang tumutugmang landas, o ang pamalit. Isang node sa bawat pagkakataon ang inuusad ng mga run, at naitatala muna ang bawat hakbang bago angkinin ang susunod, kaya ang muling pagsisimula ay nagpapatuloy kung saan talaga nakarating ang run sa halip na ulitin ito mula sa umpisa. Sinusuri ang mga webhook bago tawagan: kailangang pampublikong https address ang target, ang mga address na inaprubahan ng pagsusuri ang siyang pinupuntahan ng request, hindi sinusundan ang mga redirect, at pinuputol ang tawag na nakabitin.

AI orchestration, at paano nagsasara ang siklo

Ang mga surface sa itaas ay iniiwan pa rin sa inyo ang pag-uugnay ng mga hakbang: mapansin ang isang bagay, alamin kung kanino ito tumutukoy, magpasya kung ano ang gagawin. Kayang patakbuhin ng Prodantix ang siklong iyon nang mag-isa. Natutukoy ng engine ang mahalagang sandali sa buhay na state, pinipili ang cohort na saklaw nito, at pinipili ang aksyon. Ang nagpapalampas dito sa karaniwang automation ay ang huling bahagi: naitatala ang aksyon bilang isang event, kaya bumabalik ito sa parehong user state na babasahin ng susunod na desisyon. Ang sariling asal ng sistema ay nagiging bahagi ng nalalaman nito tungkol sa taong iyon, sa halip na isang bagay na nangyari sa kanya sa gilid.

Naghihintay ng tao ang isang panukala

Hindi kumikilos ang engine batay sa sarili nitong konklusyon. Ang nililikha nito ay panukala, at ang panukala ay nakasulat na plano: ang mga flag na ito, ang mga cohort na ito, ang mensaheng ito. Bago ito maaprubahan, bawat flag, cohort at usapang binabanggit nito ay tinutugma laban sa inyong sariling tenant, at ang sanggunian na hindi tumutugma ay nagpapabagsak sa buong panukala sa halip na tahimik na alisin, at iyon ang pumipigil sa isang modelong nakabasa ng mapaminsalang bagay na makaabot sa labas ng inyong proyekto. Gawa ng tao ang pag-apruba, at iyon ang puntong may nangyayari: dumadaan ang pagpapatupad sa parehong mga daanan ng flag at mensahe na ginagamit ninyo nang manu-mano, kaya nananatiling umiiral ang mga pahintulot, ang audit trail at ang mga hangganan ng inyong plano. Ang pag-apruba nang dalawang beses ay walang ginagawa sa pangalawang pagkakataon.

Pagpapasok ng mga event

Nagsisimula ang lahat sa isang event na ipinapadala sa ingest endpoint, na agad isinasama ng engine sa user state. May SDK para sa web, mobile at server. Ang React lang ang eksepsiyon: kailangan ng lifecycle nito ng natatanging adapter, isang provider at hook na minsan lang mag-i-install ng client at ligtas sa StrictMode. Ikinakabit ito ng quickstart sa ilang linya.

Mga key at environment

Bawat tawag ng SDK ay may dalang project key, na galing sa console. Ang paggawa ng proyekto ay lumilikha ng dalawang environment, live at test, bawat isa may sariling key: bumuo gamit ang test, maglabas gamit ang live. Parehong key ay ipinapakita nang isang beses lamang, pagkatapos ng paggawa, dahil hash lang ang iniimbak ng server at wala nang screen na makapagpapakita ulit. Ang rotation ay gumagawa ng kapalit para sa piniling environment, at kayo ang magpapasya kung titigil agad ang lumang key o pagkatapos ng palugit.

Apat na paraan para makipag-usap dito

Ang REST ay nasa tatlong host: isa para sa flags at messaging, isa para sa pagtanggap ng event, at isa para sa session replay, bawat isa ay may sariling OpenAPI document sa /openapi.json. Sumasagot ng 202 ang ingestion, ibig sabihin tinanggap ang event para iproseso at hindi pa naiimbak: puwede pa ring ma-drop ang maling event sa dulo ng pipeline. Sinasaklaw ng GraphQL ang buong application model, kasama ang mga proyekto, flag, workflow, analytics, messaging, cohort at billing. Ang realtime na surface ay nagbo-broadcast ng pagbabago sa flag, mensahe at workflow run, at agad na pinuputol ang hindi awtorisadong koneksyon. Hinahayaan ng MCP na surface ang mga AI agent na magbasa at magsulat sa pamamagitan ng tool call; machine to machine ito at tumatanggi sa mga kahilingan mula sa browser.

Nananatiling sa inyo ang datos

Puwede ninyong patakbuhin ang Prodantix sa aming mga server o sa inyong sarili, at pareho lang ang gana nito. Lahat ng inilagay ninyo rito ay maibabalik ninyo nang buo, kahit kailan ninyo gusto. Hindi namin ibinebenta ang inyong datos at hindi namin ito ginagamit sa pagsasanay ng mga AI model. Dahil sa disenyo nito, ang Prodantix ang humahawak ng pinakakumpletong tala ng inyong mga customer na mayroon kayo kahit saan, kaya mas mabigat ang pangakong iyon dito kaysa sa ibang lugar.

Para kanino ito

Bagay ang Prodantix sa mga koponang nagpapatakbo ng dalawa o tatlong magkakahiwalay na tool para dito at pagod na sa hindi nila pagkakasundo. Pinakamakabuluhan ito kapag dumami na ang inyong customer at hindi na ninyo kayang subaybayan ang ginagawa nila sa pamamagitan lang ng pagtatanong.

Bisitahin Prodantix: prodantix.com