Tinitingnan ng Amazon ang pag-uugnay ng mga account batay sa pagkakapareho ng registration data, katangian ng device at browser, network egress, bayad at payout, at asal sa produkto at operasyon. Sa maraming tindahan, kailangang magkahiwalay ang bawat kategorya dahil kahit isang shared na elemento ay maaaring makasira sa isolation.
Kapag sabay-sabay na pinapatakbo ang ilang Amazon store, ang tunay na problema ay hindi lang kapag nagkaproblema ang isang store. Mas mahirap kapag ang mga pagkakapareho sa pagitan ng mga store ay nagdurugtong sa kanila bilang iisang network. Hindi kailanman umaasa ang Amazon sa iisang salik para tukuyin kung magkakaugnay ang mga account. Maraming signal ang sabay-sabay nitong ikinukumpara, at habang mas marami ang nagkakatugma, mas mukhang iisang operator ang nagpapatakbo sa mga ito.
Maaaring hatiin sa limang pangunahing kategorya ang mga signal na ito: registration data, mga katangian ng device at browser, network egress, bayad at payout, at asal sa produkto at operasyon. Sa pagpapatakbo ng maraming store, kailangang independiyente ang bawat isa sa limang kategoryang ito; hindi sapat na isang bahagi lang ang maayos na ihiwalay.
Nakasalalay ang paghusga sa pag-overlap ng mga signal
Patuloy na kumokolekta ng data ang platform habang nagrerehistro, nagla-log in, at nagpapatakbo ng store. Kadalasan, kaunti lang ang ibig sabihin ng isang piraso ng data: normal lang, halimbawa, na mag-log in ang mga empleyado ng dalawang kumpanya na nasa iisang lungsod. Ngunit nag-iiba ang sitwasyon kapag sabay-sabay na tumutugma ang email address, phone number, payout account, mga parameter ng device, at egress address.
Kaya ang pag-iwas sa account association ay hindi tungkol sa paghahanap ng isang nakatagong setting. Ang mahalaga ay tiyaking walang overlap sa limang kategorya ng impormasyon. Ang shared na elemento sa alinmang isang kategorya ay maaaring bumawi sa isolation na ginawa sa iba.
Pinakamadaling makaligtaan ang registration data
Manu-manong inilalagay ang bahaging ito, kaya madali rin itong makopya nang hindi sinasadya. Dapat may one-to-one na pagtutugma sa bawat store ang email address, phone number, contact details, return address, at impormasyon ng entity ng store.
Karaniwang pagkakamali ang paggamit ng iisang phone number para tumanggap ng verification code ng ilang store. Sa system, nagiging mismong tali ang numerong ito na nagdurugtong sa mga store at maaari pa nitong ilantad ang ugnayan nang mas maaga kaysa sa egress address. Katulad din ang epekto ng paggamit ng eksaktong parehong return address.
Nag-iiwan ng bakas ang device at browser
Maaaring maitala ang cookies, cache, local storage, pati canvas at graphics rendering, listahan ng font, resolution, at mga hardware parameter.
Mahalaga rin ang pagkakaugnay-ugnay ng mga setting. Dapat tugma ang time zone at language na ipinapakita ng browser sa egress region na nakatalaga sa store. Kahit magkakahiwalay ang mga parameter, kung nagsasalungatan ang mga ito, hindi pa rin natural ang kombinasyon. Mahirap ding tunay na paghiwalayin ang mga katangian kapag paulit-ulit na nagpapalit ng login sa backend ng ilang store gamit ang iisang browser, kahit nililinis ang data sa bawat pagkakataon.
Hindi dapat minamaliit ang network egress
Ang paggamit ng iisang network egress para sa maraming store ay isa sa pinakadirektang signal ng association. Maaari ring isama sa paghusga ang madalas na pagpalit ng egress region at ang paulit-ulit na paglitaw ng magkakahawig na address range mula sa iisang provider.
Mahalaga rin ang kalidad ng egress. Karaniwang mas mababa ang reputasyon ng mga address range ng data center kaysa sa residential address range. Kung maraming store ang gumagamit ng ganitong uri ng address, nagkakaroon ng isa pang magkakaparehong katangian.
Maaaring pagdugtungin ng bayad at payout ang dalawang entity
Dapat tumugma ang payout account sa entity ng store at hindi ito dapat mag-overlap sa ibang store. Ganoon din ang prinsipyong dapat sundin sa payment method na ginagamit sa pagsingil ng mga fee.
Mahalaga ang layer na ito dahil sabay nitong dala ang impormasyon tungkol sa entity at ang daloy ng pera. Kapag iisang card o iisang payout account ang ginagamit ng dalawang store, hindi lang magkatulad na technical characteristic ang nakikita ng platform; maaari rin nitong makita na posibleng iisa ang business operator.
Pag-overlap ng product information at ritmo ng operasyon
Ang parehong set ng product images sa ilang store, direktang kinopyang mga talata ng description, o ganap na magkaparehong internal SKU coding rule ay lumilikha ng malinaw na pattern ng duplication. Sa pinakamababa, kailangang muling ayusin ang mahahalagang bahagi ng mga image at description.
Mas pino pa ang behavioral signals: oras ng login, ritmo ng pag-list ng produkto, ritmo ng pagsagot, at oras ng pagproseso ng order. Kapag laging ginagawa ng ilang store ang parehong bagay sa parehong oras, malinaw ang pattern. Ang pagre-review o pagrerekomenda ng mga store sa isa't isa ay gumagawa rin ng sariling association structure, at kadalasan ay mas malaki ang kapalit kaysa sa inaakala.
Kailangan ng kumpletong isolation system para sa maraming store
Masyadong kumplikadong panatilihing hiwalay ang lahat ng limang kategorya kung memorya lang ang aasahan. Kapag lumalaki ang operasyon, kailangan ng suporta sa tool level: igrupo ang mga environment ayon sa store, hiwalay na i-save ang login state at fingerprint parameter ng bawat environment, at magtalaga ng team permission ayon sa store. Ang multi-account environment capability ng PurpleMark ay para mismo sa ganitong uri ng sitwasyon.
Ilang partikular na tanong
Maaari bang gumamit ang ilang store ng iisang business license? Usapin ito ng platform policy. Maaaring mag-iba ang mga requirement depende sa marketplace at panahon, kaya dapat sundin ang kasalukuyang policy ng platform.
Sapat na bang palitan ang egress address? Hindi. Isa lang ang network sa limang kategorya; kailangan ding maging hiwalay ang environment at account information.
Maaari bang magpadala ng produkto ang mga store sa isa't isa? Kailangang maging napakaingat. Maaari ring gawing batayan ng association ang pag-overlap ng shipping address at logistics information.
Sa aktuwal na pagpapatupad, walang shortcut sa pag-iwas sa association. Ang mahalaga ay panatilihing independiyente ang limang dimensiyon nang sabay-sabay. Makakatulong ang comparison table: isang dimensiyon sa bawat row at isang store sa bawat column, pagkatapos ay suriin bawat cell kung tunay na hiwalay ang setup. Mas maaasahan ito kaysa umasa sa memorya.
