Compare several phone account checks without merging their registered, not registered and unknown answers into a misleading score.
Each selected product answers a platform-specific account question; retain each result and unknown state independently.
When checking several platforms for one phone list, keep a separate result for each selected product and each original row. A registered result for one platform does not answer the question for another, and unknown is not a negative. Compare the product-specific observations side by side with their check time rather than collapsing them into a single account score.
Define the question for each selected product
NumDetect lets a team select several phone products for the same list without uploading it again. That is convenient for a mixed-channel workflow, but it does not make the products interchangeable. A WhatsApp registration answer is about WhatsApp; a Telegram answer is about Telegram; a social-network product answers only its named platform. Each result is a platform-specific account registration signal at the time of checking. A positive result on one platform cannot be copied into another product’s column, and a negative result on one platform cannot cancel a positive result elsewhere.
Start with the team’s actual operational question. If the purpose is to decide which channel to review for an opted-in contact list, select only relevant products. Record the chosen product name with every observation. The current phone catalogue includes messaging, social, consumer and regional platform checks, but a report need not include all of them to be useful. Product choice belongs before interpretation: a broad score cannot repair a product selection that did not address the intended channel.
Preserve three states per product
The current result model is registered true, registered false, or null/unknown. True and false are conclusive answers for the selected product at that check time. Unknown means the product did not provide a conclusive answer; it must remain unknown in the reporting table. A failed product does not stop the other selected checks, so a row can contain a usable result for one platform and an unresolved result for another. Do not make an “all platforms absent” label when one of the relevant columns is unknown.
A practical customer-owned reporting view can use original row reference, normalized phone input, product, check time, and one of the three states. These are suggested report columns, not an invented universal response envelope. Keep the source result available for audit. NumDetect retains original row order and source row references in bulk results, which helps the team link a result back to the imported list. Preserve that mapping when exporting CSV or joining to a CRM; row position alone should not become a permanent customer identifier.
Compare observations without inventing a composite score
A side-by-side table can answer a narrow question: which selected products returned conclusive registration signals for this submitted number? It should display one named product per column or row and show unknown distinctly. A count of positives can be useful only as a clearly defined internal summary of those particular selected checks; it is not a verified engagement, value, identity or risk score. Avoid ranking people by a fabricated cross-platform measure. A platform answer says nothing about whether the contact owns the number, wants outreach, recently used the account, or will reply.
A reader can instead choose a rule tied to the task. For example, an operations team may send a row with unknown on its intended channel to manual review, while retaining a separate conclusive result for another selected channel. That rule is a customer decision, not a NumDetect product requirement. Keep the decision record separate from the raw observations so later reviewers can change the policy without rewriting what was actually checked.
Keep product and time attached during review
A report should never merge different products, or checks from different dates, under one unlabeled “registered” column. A bulk list shows its cost before it runs; a single check is charged only for a conclusive answer, while each country in a bulk list is charged in full once it completes, unknown rows included. Those billing facts do not expand what the signals mean.
Review each product’s current country coverage in the product list before running a mixed-country list. A product unavailable for one group should not be reported as a negative account finding. When a finished list is downloaded, keep each row with its product columns and check time intact. The developers overview is a starting point for the documented flow; the API documentation supplies exact fields. The next practical step is a small report that exposes each product’s true, false or unknown result independently and leaves any channel decision to a clearly stated team policy.
FAQ
Does registration on one platform imply registration on another?
No. Each selected product gives its own platform-specific answer at check time.
Should unknown be counted as not registered?
No. Unknown means no conclusive answer for that product and must stay separate from registered false.
Can results from different dates be combined?
Label them with their check dates. An account can be created or removed between checks, so an older result does not describe today.
Learn More
Choose the product information that fits the next step in your workflow.
Sources
Prepared from NumDetect product documentation and the cited sources.