როგორ გავარჩიოთ დუბლირებული ლიდი უნიკალური მოთხოვნისგან
ანალიტიკოსი ლიდების დუბლირების წესში წერს ტექნიკური მოვლენის ID-ს, ნორმალიზებულ კონტაქტს, მოთხოვნის საგანს, დროსა და CRM-ის გადაწყვეტილებას.
მოკლე პასუხი: დუბლირებული ლიდი ერთი მოთხოვნის განმეორებითი ჩანაწერია, ხოლო უნიკალური მოთხოვნა ცალკე საქმიანი საჭიროებაა. ტექნიკური მოვლენის ID-ით მხოლოდ მიწოდების დუბლიკატის პოვნა შეიძლება. პირის, მოთხოვნისა და შესაძლებლობის გასარჩევად დამატებით შეადარეთ ნორმალიზებული კონტაქტი, მოთხოვნის საგანი, დრო და CRM-ის ჩანაწერზე პასუხისმგებელი თანამშრომლის გადაწყვეტილება.
ლიდების დუბლირების წესზე მოკლე კონსულტაციისთვის დაუკავშირდით aiADS-ის გუნდს.
რატომ ვერ დავახარისხებთ ოთხ სასწავლო ჩანაწერს ერთი წესით?
ოთხ ჩანაწერს ერთი წესით ვერ დავახარისხებთ, რადგან ტექნიკური დუბლიკატი, განმეორებითი კონტაქტი და ახალი საქმიანი მოთხოვნა სხვადასხვა მტკიცებულებას მოითხოვს. „ქალაქის ფანჯარა“ და ქვემოთ მოცემული ყველა ჩანაწერი გამოგონილი სასწავლო მაგალითია. კომპანია aiADS-ის კლიენტი არ არის. ცხრილი არ ასახავს რეალურ ლიდებს, კამპანიის შედეგს ან კონვერსიის მაჩვენებელს.
სასწავლო კომპანია ფანჯრებს ზომავს და ამონტაჟებს. ანალიტიკოსი ჯერ ტექნიკურ გასაღებს ამოწმებს, შემდეგ კონტაქტს, მოთხოვნის საგანსა და გაყიდვების ჩანაწერს. სტატუსთან ერთად გადაწყვეტილების მიზეზიც ინახება.
| სასწავლო ჩანაწერი | რა დაემთხვა | გადაწყვეტილება | რატომ |
|---|---|---|---|
| A | იგივე შიდა მოვლენის ID, იგივე ფორმა და იგივე მოთხოვნა | ტექნიკური დუბლიკატი | ინტეგრაციამ ერთი მოვლენა ხელახლა მიაწოდა |
| B | იგივე ტელეფონი, სხვა მისამართი და სხვა სამუშაო | ახალი მოთხოვნა | არსებულ კონტაქტს ახალი საქმიანი საჭიროება აქვს |
| C | საერთო ელფოსტა, განსხვავებული პასუხისმგებელი და ობიექტი | ხელით შესამოწმებელი | კონტაქტის დამთხვევა მოთხოვნის დამთხვევას არ ამტკიცებს |
| D | ბრაუზერისა და სერვერის მიწოდება ერთ ქმედებას აღწერს | ერთი პლატფორმული კონვერსია | ორივე მიწოდებას პლატფორმისთვის ერთი ტრანზაქციის ID უკავშირდება |
ამ ოთხი ჩანაწერის შედარებით ანალიტიკოსი ტექნიკურ დუბლიკატს, განმეორებით კონტაქტსა და ახალ შესაძლებლობას ერთმანეთისგან არჩევს. „ერთი ტელეფონი, ერთი ლიდი“ ამისთვის საკმარისი წესი არ არის, რადგან თითოეული შემთხვევა სხვადასხვა გადაწყვეტილებას მოითხოვს.
როგორ იყენებს ანალიტიკოსი თითოეულ ველს მოთხოვნის იდენტობის შესამოწმებლად?
ანალიტიკოსი შიდა მოვლენის ID-ით ბრაუზერისა და სერვერის ჩანაწერებს აკავშირებს, Google Ads-ის ტრანზაქციის ID-ით ერთი კონვერსიის განმეორებით მიღებას ამოწმებს, CRM-ის კონტაქტის ID-ით პირს ან ორგანიზაციას ამოიცნობს, შესაძლებლობის ID-ით კი კონკრეტულ საქმეს. თითოეულ ველში განსხვავებული იდენტიფიკატორი ინახება, ამიტომ ისინი ერთმანეთის შემცვლელი არ არის.
| ველი | რაში იყენებს გუნდი | რატომ არ არის მარტო საკმარისი |
|---|---|---|
| შიდა მოვლენის ID | ბრაუზერისა და სერვერის ჩანაწერების ერთ ქმედებასთან კავშირის შესამოწმებლად | პირის ან საქმიანი საჭიროების იდენტობას ვერ ადგენს |
| პლატფორმის ტრანზაქციის ID | ერთი კონვერსიის პლატფორმაში განმეორებით მიღების შესამოწმებლად | CRM-ის კონტაქტისა და შესაძლებლობის სტატუსს არ ცვლის |
| ნორმალიზებული კონტაქტი | ტელეფონის ან ელფოსტის უკვე არსებობის შესამოწმებლად | გაზიარებული ნომერი და საერთო ელფოსტა შეიძლება რამდენიმე პირს ეკუთვნოდეს |
| მოთხოვნის საგანი | მომსახურების, ობიექტისა და საჭიროების შესაძლო განმეორების შესაფასებლად | თავისუფალი ტექსტი შეიძლება არასრული იყოს |
| დრო და წყარო | ჩანაწერების დროითი სიახლოვისა და მიწოდების წყაროს შესადარებლად | ახალი მოთხოვნა იმავე დღესაც შეიძლება წარმოიშვას |
| CRM-ის გადაწყვეტილება | პასუხისმგებელი თანამშრომლის მიერ ერთი ან რამდენიმე შესაძლებლობის დასაფიქსირებლად | ერთიანი წესი და წერილობითი მიზეზი სჭირდება |
იდენტიფიკაციის ბარათს გადაწყვეტილების ისტორია დაურთეთ. შეინახეთ, რომელი ველები დაემთხვა, ვინ გადაწყვიტა გაერთიანება ან განცალკევება და რომელი ჩანაწერი დარჩა მთავარ შესაძლებლობად. მხოლოდ საბოლოო სტატუსი საკმარისი არ არის: თუ წესს მოგვიანებით შეცვლით, ძველი გაერთიანების მიზეზს ვეღარ აღადგენთ და იგივე ტიპის დამთხვევას განსხვავებულად დაამუშავებთ.
ავტომატური წესი მხოლოდ მკაფიო ტექნიკურ დუბლიკატზე გამოიყენეთ. ნაწილობრივი დამთხვევისას, მაგალითად საერთო ტელეფონისა და განსხვავებული ობიექტის შემთხვევაში, ანალიტიკოსმა ჩანაწერი ხელით შემოწმებას უნდა მიაკუთვნოს, ან კონფიგურირებულმა მარშრუტიზაციის კომპონენტმა ის შემმოწმებელს უნდა გაუგზავნოს. შემმოწმებელმა ორივე ჩანაწერის შინაარსი უნდა ნახოს, არა მხოლოდ ერთი შერჩეული ველი. ასე ახალი საქმიანი მოთხოვნა ძველ კონტაქტს უკავშირდება, მაგრამ არსებულ შესაძლებლობას ავტომატურად და კვალის გარეშე არ უერთდება.
რის ამოცნობაში იყენებს Google Ads ტრანზაქციის ID-ს?
Google Ads ტრანზაქციის ID-ს ერთი კონვერსიის მოქმედებაში განმეორებით მიღებული კონვერსიის ამოსაცნობად იყენებს; იგი ადამიანის ან საქმიანი მოთხოვნის იდენტობას არ ადგენს. Google Ads-ის ტრანზაქციის ID-ის სახელმძღვანელოს მიხედვით, უნიკალური იდენტიფიკატორი შეიძლება შეიცავდეს მაქსიმუმ 64 სიმბოლოს. თუ ერთი კონვერსიის მოქმედების 2 კონვერსიას იგივე ID აქვს, პლატფორმა მეორეს დუბლიკატად ცნობს.
შიდა მოვლენის ID, Google-ის ტრანზაქციის ID, CRM-ის კონტაქტის ID და შესაძლებლობის ID შეიძლება ერთმანეთთან იყოს დაკავშირებული, მაგრამ მათი მნიშვნელობა წერილობით უნდა განისაზღვროს. ყველა ველში ერთი მნიშვნელობის მექანიკურად ჩაწერა იდენტიფიკატორების დანიშნულებასა და მოქმედების ფარგლებს ერთმანეთში ურევს.
რა უნდა გადავამოწმოთ საბოლოო გადაწყვეტილებამდე?
საბოლოო გადაწყვეტილებამდე გადაამოწმეთ ტექნიკური ქმედების, პირისა და საქმიანი მოთხოვნის იდენტობა.
- იგივე ტექნიკური ქმედებაა? შეადარეთ შიდა მოვლენის ID, პლატფორმის ტრანზაქციის ID, დრო და მიწოდების წყარო.
- იგივე პირია? შეადარეთ ნორმალიზებული ტელეფონი და ელფოსტა, მაგრამ გაზიარებული კონტაქტი ავტომატურად არ გააერთიანოთ.
- იგივე საქმიანი მოთხოვნაა? შეამოწმეთ მომსახურება, ობიექტი, საუბარი და გაყიდვების შემდეგი ნაბიჯი.
გაურკვეველი დამთხვევის მქონე ჩანაწერი ხელით შესამოწმებლად მონიშნეთ და პასუხისმგებელ თანამშრომელს მიანიჭეთ. ავტომატური გაერთიანება მხოლოდ იმ წესზე გამოიყენეთ, რომლის მცდარი გაერთიანების რისკი წინასწარ გაქვთ შეფასებული. გადაწყვეტილებას მიზეზი დაურთეთ, რათა ინტეგრაციის ცვლილების შემდეგ იგივე შემთხვევა ხელახლა გამოცადოთ.
თუ ჩანაწერები გააერთიანეთ, გაერთიანებული ჩანაწერის კვალი არ წაშალოთ. მთავარ შესაძლებლობას მიუთითეთ გაერთიანებული ჩანაწერის იდენტიფიკატორი, დრო და წყარო. თუ ცალ-ცალკე დატოვეთ, ორივე შესაძლებლობას დაურთეთ მოკლე განმარტება, რომ კონტაქტის დამთხვევის მიუხედავად განსხვავებული საჭიროება დადასტურდა. შენახული ჩანაწერებით გაყიდვებისა და ანალიტიკის გუნდები გაარკვევენ, რატომ მიიღეს კონკრეტული გადაწყვეტილება.
რით განსხვავდება პლატფორმის დათვლა CRM-ის აღრიცხვისგან?
პლატფორმა კონვერსიის ტექნიკურ ჩანაწერებს ითვლის, CRM-ში კი პასუხისმგებელი თანამშრომელი კონტაქტებსა და ცალკეულ საქმიან მოთხოვნებს აღრიცხავს.
| ფენა | რას აღრიცხავს | სწორი კითხვა |
|---|---|---|
| რეკლამის პლატფორმა | კონვერსიის ტექნიკური ჩანაწერი | ერთი კონვერსია რამდენჯერ მივიღეთ? |
| CRM-ის კონტაქტი | ადამიანი ან ორგანიზაცია | ეს კონტაქტი უკვე არსებობს? |
| CRM-ის შესაძლებლობა | კონკრეტული საჭიროება | ეს იგივე საქმეა თუ ახალი მოთხოვნა? |
| გაყიდვებზე პასუხისმგებელი თანამშრომელი | CRM-ში მინიჭებულ სტატუსსა და შეთანხმებულ შემდეგ მოქმედებას ამოწმებს | რომელი მოთხოვნის დამუშავება დაიწყო? |
Google Ads-ის კონვერსიების დათვლის დოკუმენტაცია განმარტავს, რომ „One“ პარამეტრი თითო სარეკლამო დაწკაპუნების შემდეგ 1 კონვერსიას ითვლის. ეს პარამეტრი სხვადასხვა წყაროში ერთ ადამიანს და მის სხვადასხვა საქმიან მოთხოვნას ვერ განასხვავებს. CRM-ში კონტაქტისა და შესაძლებლობის ცალკე აღრიცხვა კვლავ საჭიროა.
სად არის დუბლირების წესის ზღვარი და როდის გვჭირდება ხელით შემოწმება?
დუბლირების წესის ზღვარი ბუნდოვანი დამთხვევაა, ხოლო ხელით შემოწმება საჭიროა მაშინ, როცა ავტომატურმა გაერთიანებამ შეიძლება ცალკე საქმიანი მოთხოვნები ერთ ჩანაწერად აქციოს. გაზიარებული კონტაქტები, შეცვლილი ნომრები, მცდარად შეყვანილი ელფოსტა და მოკლე შეტყობინებები ასეთ ბუნდოვან დამთხვევებს ქმნის. მაღალი რისკის გაერთიანება პასუხისმგებელმა თანამშრომელმა უნდა გადაამოწმოს.
თუ ბრაუზერისა და სერვერის მიწოდებებს სხვადასხვა შიდა ID აქვს და ერთიანი ტრანზაქციის გასაღები არ ახლავს, პლატფორმის აღრიცხვაში ისინი ორ დამოუკიდებელ ქმედებად შეიძლება დაფიქსირდეს. ამავე დროს, ერთი ტექნიკური გასაღების არსებობა ორ სხვადასხვა ბიზნესმოთხოვნას ავტომატურად არ გამორიცხავს. ტექნიკური და საქმიანი წესები ცალ-ცალკე შეამოწმეთ.
დუბლიკატების თავიდან აცილების ან აღმოჩენის მიზანი ზედმეტი პირადი ინფორმაციის შეგროვებას არ ამართლებს. შეინახეთ მხოლოდ ის ველები, რომელთა მიზანი, წვდომა და შენახვის წესი განსაზღვრულია.
როგორ შევამოწმეთ მასალა?
მასალა 2026 წლის 8 აგვისტოს გადავამოწმეთ Google Ads-ის ტრანზაქციის ID-ისა და კონვერსიების დათვლის დოკუმენტაციასთან. ქართულენოვანი ძიების შედეგებში მოთხოვნის ტექნიკური იდენტობისა და საქმიანი შესაძლებლობის გამიჯვნის პრაქტიკული პასუხი ვერ ვიპოვეთ. aiADS-ის კორპუსში მაქსიმალური თემატური მსგავსება ბლოკირების ზღვარს მნიშვნელოვნად ჩამორჩა. Search Console-ის მონაცემი ხელმისაწვდომი არ იყო. „ქალაქის ფანჯარა“ გამოგონილი სასწავლო მაგალითია.
რომელ კითხვებს სვამენ ყველაზე ხშირად?
ყველაზე ხშირად გუნდი ტელეფონის დამთხვევაზე, ერთი ადამიანის ახალ მოთხოვნაზე, Google Ads-ის დათვლის წესსა და ბუნდოვანი შემთხვევის დამუშავებაზე კითხულობს.
იგივე ტელეფონი ყოველთვის დუბლიკატს ნიშნავს?
არა. იგივე ტელეფონი დამთხვევის ძლიერი ნიშანია, მაგრამ გადაწყვეტილებისთვის პასუხისმგებელმა თანამშრომელმა მოთხოვნის საგანი, ობიექტი და დროც უნდა შეაფასოს. გაზიარებულ ნომერზე რამდენიმე რეალური მოთხოვნა შეიძლება მოვიდეს.
შეიძლება ერთი ადამიანი რამდენჯერმე ჩაითვალოს უნიკალურ მოთხოვნად?
შეიძლება, თუ ადამიანს ახალი საჭიროება, სხვა ობიექტი ან ცალკე კომერციული პროცესი აქვს. კონტაქტი იგივე რჩება, შესაძლებლობა კი ახალი იქმნება.
საკმარისია Google Ads-ის Count პარამეტრი?
Count-ის პარამეტრი მხოლოდ პლატფორმის დონეზე მართავს კონვერსიის დათვლას. სხვადასხვა წყაროში ერთი პირისა და რამდენიმე საქმიანი მოთხოვნის გასარჩევად CRM-ში იდენტიფიკაციის წესი საჭიროა.
რა ვუყოთ გაურკვეველ დამთხვევას?
ჩანაწერი ხელით შესამოწმებლად მონიშნეთ, პასუხისმგებელ თანამშრომელს მიანიჭეთ, შეადარეთ საუბარი და მოთხოვნის საგანი, შემდეგ გადაწყვეტილება მიზეზთან ერთად შეინახეთ. გაურკვეველი ჩანაწერი ავტომატურად არ გააერთიანოთ.
რა უნდა შევამოწმოთ დუბლირების შემდეგ?
დუბლირების შემდეგ შეამოწმეთ მთავარი კონვერსიის მოვლენა, უარის მიზეზების კავშირი რეკლამასთან და ტრეკინგის სრული თანმიმდევრობა.