Niezawodna identyfikacja to klucz do utrzymania porządku w bazie danych Positive User. Gdy poprawnie identyfikujesz swoje rekordy, masz pewność, że automatyzacje uruchamiają się dla właściwych osób, a dane z zewnętrznych systemów trafiają do odpowiednich profili. Wybór właściwego identyfikatora pozwala uniknąć duplikatów i zapewnia spójny sposób śledzenia ścieżek Twoich kontaktów.
Rozumiejąc różnicę między identyfikatorami generowanymi przez system a definiowanymi przez użytkownika, Twój zespół może zbudować bezpieczniejszą i bardziej skalowalną strukturę danych.
W Positive User masz trzy podstawowe sposoby identyfikacji obiektów, takich jak kontakty, firmy i szanse sprzedaży. Każdy z nich służy innym celom, w zależności od tego, jak zarządzasz danymi.
System ID to stały, unikalny numer przypisywany przez Positive User w momencie utworzenia obiektu. Znajdziesz go na końcu adresu URL w pasku przeglądarki, gdy przeglądasz konkretny profil.
Charakterystyka: jest niezmienny — nie można go edytować ani usunąć.
Najlepszy do: wewnętrznych odwołań systemowych oraz zaawansowanych operacji w REST API.
Custom ID to standardowy atrybut, który domyślnie jest pusty — to Ty decydujesz, jaką wartością zostanie wypełniony. Często jest importowany z zewnętrznej bazy danych, CRM-a lub sklepu internetowego (np. Shopify ID). W odróżnieniu od System ID, jest przechowywany jako konkretne pole w profilu obiektu.
Charakterystyka: jest elastyczny i pozwala zniwelować różnice między Positive User a innymi narzędziami.
Najlepszy do: zapewnienia, że kontakt X w Twoim zewnętrznym systemie to zawsze ten sam kontakt X w Positive User. Sprawdza się również przy łączeniu obiektów ze sobą (np. przypisywaniu kontaktów do firm).
Dla większego bezpieczeństwa nie używaj zwykłych adresów e-mail jako Custom ID dla kontaktów. Aby właściwie chronić dane wrażliwe, wartości te powinny zostać zahashowane lub zakodowane przed wysłaniem do Positive User.
W przypadku kontaktów adres e-mail może pełnić rolę naturalnego identyfikatora. To najbardziej powszechny sposób rozpoznawania osób, które wypełniają Twoje formularze lub wchodzą w interakcje z kampaniami.
Charakterystyka: umożliwia bardzo łatwą deduplikację. Jeśli nie masz osobnego numerycznego ID z zewnętrznej bazy danych, użycie adresu e-mail jest zdecydowanie zalecane.
Najlepszy do: automatycznego utrzymywania porządku w bazie danych.
Każdy kontakt domyślnie ma System ID. Oto jak wybrać właściwy główny identyfikator do codziennej pracy:
Kiedy używać adresu e-mail: to zazwyczaj najlepsza opcja. Skutecznie zapobiega duplikatom, gdy ludzie wypełniają formularze, zapisują się na newslettery lub wchodzą w interakcje z kampaniami. Ta opcja nie pozwala na utrzymywanie wielu kontaktów z tym samym adresem e-mail.
Kiedy używać Custom ID: wybierz tę opcję, jeśli Twoja zewnętrzna platforma (np. własna aplikacja) generuje własne unikalne numery. Dzięki temu oba systemy pozostają idealnie zsynchronizowane, a dodatkowo zyskujesz warstwę bezpieczeństwa, jeśli zdecydujesz się hashować wartości. Zaleca się przypisywanie Custom ID do identyfikacji kontaktów, ponieważ są to potwierdzone, zweryfikowane rekordy.
Kiedy używany jest System ID: jeśli nie podano ani adresu e-mail, ani Custom ID, Positive User polega na System ID i plikach cookie przeglądarki, aby tymczasowo śledzić daną osobę jako anonimowy kontakt.
Kiedy używać Custom ID: jest niezwykle przydatny przy automatycznym przypisywaniu kontaktów do firm. Dołączając atrybut „company_id” do pliku podczas importu, Positive User natychmiast łączy osoby z właściwym profilem firmy.
Kiedy wystarczy System ID: użyj tej opcji, jeśli Twój zespół buduje lejek sprzedażowy ręcznie w aplikacji i nie ma potrzeby synchronizacji rekordów firm z zewnętrznym narzędziem księgowym.
Logika dla szans sprzedaży i zgłoszeń jest taka sama jak w przypadku firm i kontaktów.
Rola System ID: w codziennej pracy w lejku sprzedażowym lub helpdesku będziesz polegać na automatycznie generowanym System ID. Aplikacja obsługuje śledzenie w tle, gdy przesuwasz elementy między etapami.
Kiedy używać Custom ID: Custom ID (np. deal ID lub identyfikator zgłoszenia z innego systemu) staje się niezbędny, gdy Twoi deweloperzy muszą zdalnie aktualizować statusy lub ustawiać konkretne atrybuty za pomocą REST API, albo gdy potrzebujesz przypisać te obiekty do innych (np. zaimportować zadania i przypisać je do szans sprzedaży).
Inne obiekty w systemie, takie jak zgłoszenia, można obsługiwać w ten sam sposób — używając System ID do wewnętrznej nawigacji w aplikacji i Custom ID do aktualizacji zewnętrznych opartych na API.
