Leads From Associations and Directories: Manage Source, Freshness, and Contact Consent

A record taken from an association membership list or a professional directory has to carry three things with it: which source exactly, the date it was pulled, and the terms the source was published under. Without all three you cannot answer the question "how did you get my details" after the fact, and that is the question that gets asked.

This is a technical description of record structure and source documentation, not legal advice.

What an official register actually gives you

The answer that surprises people is that an open government database describes a legal entity rather than a human being you can telephone. The Ministry of Justice associations database publishes, per association, fields such as association number, Hebrew name, association status, sector activity classification, address locality, address street, and the association's stated purposes.

What is not there is any field identifying a person: no contact name, no phone number, no email address. The practical consequence is that an association record from the official register is not a lead. It is an organisational anchor that somebody will have to complete from another source, and that completion is exactly where confusion about provenance begins.

• The entity and the address came from the official register, and that has documentation.
• The phone number came from the organisation's own website, and that has different documentation.
• The contact person's name came from a third place, and if that has no documentation it is effectively sourceless.

When all three parts sit in one row with no marking, the record looks uniform and is not. A source field at row level hides this. A source field at field level exposes it.

How do you record provenance so the question can be answered later?

The rule is that the answer to "how did you get my details" must be reconstructible from the record itself, without asking whoever built it and without relying on memory.

The fourth field is the forgotten one. A directory's terms of use are not an eternal document, and if you did not keep a copy or a hash of them on the day you pulled, you have no way to show what you were working under. Storing the text is cheap, and its absence surfaces only when it is already too late.

What to do with a status field and with dates

A directory is not a list of active organisations. It is a list of records with statuses, and skipping that distinction costs money.

In the first ten thousand rows of the associations database by record id, the split is 6,005 marked deleted, 3,617 marked registered, 275 voluntarily wound up and 55 under a court winding-up order. It matters to say what that does and does not show: the slice is biased, because the record id tracks registration order and these are therefore the oldest entries. It does not represent the whole file. What it does prove is that a directory file contains a great many organisations that no longer exist, and that filtering on status is not optional.

• Read the status field before any other filter.
• Filter on an explicit list of values, not on "not empty".
• Keep the status in the record, so it can be rechecked on the next pass.
• Handle date formats per column, because they are not consistent.
• Never convert a date without keeping the raw string.

The formats really do differ. Within the same row, the registration date arrives as 17/05/1981 while the status update date arrives as Nov 3 2019 7:24AM. A single converter assuming one format gives you false calm and then silent errors downstream.

What the law says, and what this article does not say

Israel's Protection of Privacy Law, 5741-1981 exists and regulates the subject of databases. Amendment 13 to that law exists. The Privacy Protection Authority is the body that publishes guidance material on the subject. The Ministry of Justice publishes on data.gov.il the register of databases, which at the time of checking holds 32,010 rows with fields such as database number, database name, categories of information, purposes, and database status.

Those are facts with an official publication you can check. What is deliberately not in this article: no statement of what you are allowed to collect, no statement of when consent is required, and no conclusion about marketing outreach. Questions of that kind depend on circumstances and on the law, and the address for them is a lawyer or the Privacy Protection Authority. The privacy angle on a customer spreadsheet is discussed in a customer spreadsheet and Amendment 13, and the technical side of public collection in is web scraping legal in Israel.

Why do directory names not match your names?

Because the official files pass through an encoding conversion that replaces the Hebrew double-quote mark with another character. In the ten thousand rows I checked, 6,482 of the Hebrew names contain a tilde where the gershayim should be, so the non-profit suffix appears as (ע~ר) rather than (ע"ר). Company names in the Registrar of Companies file show the same thing, appearing as בע~מ.

• Normalise that character before any name comparison.
• Strip the corporate suffix into a separate field rather than out of the name itself.
• Keep the raw name, because it is the evidence of what the source published.
• Never send the raw name in outreach. (ע~ר) in an email opening tells the recipient exactly what happened.
• Check an English-name field before relying on it: in the slice I measured it is empty in 9,884 of 10,000 records.

That last field is a good example of the gap between what a schema promises and what a file delivers. A column that exists is not a column that is populated, and a design assuming every organisation has an English name will break on most of the records.

Sources

• Israeli Privacy Protection Authority
• Associations and public benefit companies register, Ministry of Justice - data.gov.il
• Register of databases, Ministry of Justice - data.gov.il