Qualidade de Dados / Data Quality

Existem como foram sendo descritas ao longo dos posts anteriores várias formas de normalização, correcção, actualização e validação das moradas, sendo o tratamento em modo batch sem dúvida o mais económico, para quem não tem volume de dados que comporte a compra das aplicações que funcionam logo na entrada dos dados. Embora seja essa a forma em que sem dúvida vamos ter os melhores resultados, nem sempre é possível fazer esse investimento.

Esta forma de tratamento obriga a um ciclo de tratamentos, mais ou menos frequentes consoante o volume de dados e de alterações que existam nos dados.

Neste tratamento de dados é feita a comparação dos dados existentes, com os dados existentes no ficheiro que contem as localidades, as respectivas ruas com, em muitos casos, os respectivos números de porta. Desta forma e recorrendo aos mais avançados algoritmos combinados, conseguimos ter resultados que são em muito superiores ao que por norma se consegue verificar. A segurança e qualidade dos dados e das aplicações é tal que é possível fazer testes neste demo online.

Esta é a melhor demonstração que podemos fazer da qualidade das nossas aplicações.

Na vertente Batch, vão existir no ficheiro final campos com uma descrição de todas as alterações que tenham sido efectuadas a cada um dos registos. Existem igualmente códigos que assinalam se os registos foram ou não alterados ou se não foi possível fazer a normalização / correcção / validação dos mesmos. Existem casos em que simplesmente não é possível fazer a normalização. Podem ser inúmeras as causas para essa não normalização, especialmente num país com as particularidades de Portugal. Mas mesmo com estas particularidades, estaremos sempre a falar em percentagens de normalização muito elevadas.

Como se pode ver com ferramentas adequadas não é necessária muita informação para que se consiga obter uma morada normalizada e mais que isso, com código postal de 7 dígitos e caso seja necessário ainda com as coordenadas geográficas anexadas. Tudo isto feito de forma sistematizada e no momento mais importante e crucial de toda a vida dos dados dentro de qualquer companhia: logo na sua criação.

Ainda mais que para estes casos em que as informações são poucas, estas ferramentas servem igualmente para os casos em que há dificuldades na percepção do interlocutor, seja qual for o motivo. Para alem dos erros de percepção quer seja escrita ou de dicção, estes softwares ainda são tolerantes aos erros de digitação.

Tudo isto pode ser comprovado online neste link. Esta é a melhor demonstração que se pode dar na confiança que existe nestas aplicações.

A qualidade da informação é um conceito que tem vindo a mudar ao longo dos anos. A definição de qualidade desde os anos 70 até aos dias de hoje tem vindo a ser alterada.

Se até ao final do século passado, poderíamos considerar uma BD com qualidade, se tivesse normalizada. O que entendo aqui por normalizada? Todas as moradas por exemplo, tinham sempre "R DR XXXXX", ou "AV PROF XXXXXX".

Depois disso a definição de qualidade passou a ir um pouco mais longe e passamos apenas a considerar registos com qualidade, os registos que tivessem com uma morada totalmente correcta, em alguns casos já por extenso, algo como "Rua Doutor Xxxxxxx" ou "Avenida Professor Xxxxxxx". Mais importante, no caso Português, que tivessem também os 7 dígitos do código postal correctos. Infelizmente ainda hoje há muitas BD's que nem isto conseguem ter, existindo inúmeros registos com a terminação em 000 ou 999.

Mas agora a definição de qualidade da informação vai ainda mais longe, sendo que a tudo o que existia anteriormente, ainda temos que acrescentar as coordenadas geográficas e em muitos casos chaves comportamentais.

As necessidades de termos informação de qualidade hoje, não têm comparação com as necessidades que tínhamos há uns anos, nem certamente com as necessidades que teremos num futuro próximo.

As ferramentas Real Time de qualidade de dados funcionam tal como foi já anteriormente referido a todo o momento permitindo assim que os dados estejam sempre actualizados e que a qualquer momento a qualidade dos dados possa ser assegurada de forma a que quando a informação seja necessária ela esteja correcta e actualizada.

Desta forma podemos confiar na informação existente nas nossas BD's evitando assim os picos que surgem nos processos de ETL que vimos anteriormente. Imaginado que o ciclo implementado para os processos de ETL era de um ano, se depois de nove meses de ter sido executado um processo de ETL fosse feita uma contagem, o que iria acontecer era que provavelmente os dados não seriam de todo fiáveis. Com as aplicações a funcionar em Real Time nunca chegamos a ter dados muito incorrectos. Podem haver algumas discrepâncias nos dados, mas será sempre valores residuais.

Este gráfico mostra a diferença entre as metodologias. Se a um dado momento nos for por exemplo pedido uma contagem de residentes numa determinada rua, com as aplicações Real Time em funcionamento não necessitamos de grandes esforços de normalização para conseguirmos dar esses valores porque sabemos que essa rua está sempre escrita da mesma forma e como tal não necessitamos de queries muito complexas para obter um resultado correcto. No exemplo dado anteriormente em que um processo de ETL tenha sido executado nove meses antes, o normal será procurar uma "Rua Principal"; "R Principal"; "R. Principal" e mesmo assim não existe a certeza de termos uma contagem com todos os registos da Rua Principal. Se no lugar da Rua Principal colocarmos uma Avenida Calouste Gulbenkian as hipóteses crescem exponencialmente.

A informação cada vez mais é um bem essencial a todas a empresas e não ter acesso a essa informação rapidamente pode ter consequências catastróficas.

Muito superior ao custo de qualquer projecto de qualidade de dados, é o custo da falta de qualidade de dados. Os custos são os mais variados, desde custos directos a custos indirectos.

Nos custos directos podemos alocar os custos desde logo com a existência de duplicados e com todas as implicações que daí advêm para as companhias. O envio de correio, ou o contacto telefónico em duplicado, triplicado... alem dos custos directos, são também nos custos indirectos, uma vez que são uma má imagem de qualquer companhia. Quantos de nós não recebemos já estes contactos duplicados e sabemos que deixa uma imagem muito má de qualquer empresa. Nos custos directos ainda podemos em muitos casos colocar os custos de tempo para os vendedores para encontrarem uma morada, os custos de distribuição, os custos com as devoluções.

Nos custos indirectos temos essencialmente os custos de imagem que podem vir como anteriormente referidos pela duplicação de comunicação, mas podem ser também por dificuldade no encontrar uma ficha de cliente que quer apresentar uma reclamação porque nem se consegue encontrar a ficha ou porque como existem registos duplicados, foi encontrada uma ficha, mas não era nessa ficha que a queixa tinha anteriormente sido registada. Estes custos são os mais difíceis de contabilizar uma vez que por norma não se consegue saber o motivo que leva um cliente a sair da empresa. Se por insatisfação se por qualquer outro motivo.

Na grande maioria dos casos os projectos de limpeza de dados ou qualidade de dados, são projectos simples de ETL, em que existem várias abordagens.

Há projectos que são "simples". É feita a Extracção dos dados, o seu tratamento (Transform) e posteriormente o seu carregamento em BD (Load). Com estes projectos há uma aproximação a uma verdadeira qualidade de dados, mas se "olharem" com mais atenção vão verificar que na realidade, os dados nunca chegaram realmente a ficar limpos nos valores que são apresentados. Estes processos de ETL demoram algum tempo, e durante esse tempo, alguns dos dados que estão a ser tratados, estão a ser alterados pelos utilizadores. Ou seja, quando a BD é reposta, esses dados para alem de não poderem ser carregados, as alterações que entretanto foram efectuadas trouxeram mais "lixo" para o sistema.

E depois? Na semana seguinte a este projecto há novos dados, alterações e todo um conjunto de processos que fazem os dados voltar ao seu estado de falta de qualidade.

Existem outras abordagens, que já vi serem implementadas por grandes empresas em Portugal, que são ainda mais chocantes, que é a execução de projectos de ETL de forma progressiva. Ou seja, primeiro por exemplo tratam os registos que têm o código postal 1000. Depois os 1050 e assim sucessivamente. Este processo apenas permite que uma empresa fique eternamente a fazer a limpeza de dados, porque quando chegam ao fim do processo, estão os dados iniciais já totalmente "sujos". Apenas continuam o processo Ad aeternum.

Os processos ETL devem ser o principio de qualquer projecto de qualidade de dados. Durante o processo de ETL deve ser implementada uma solução online que permita a manutenção dos dados actualizados, evitando assim estar sempre a implementar processos ETL, com os elevados custos inerentes.

Aqui podem ver uma demonstração de como podem funcionar estas aplicações que em termos de moradas evitam a entrada de "lixo" para o sistema.

Tudo o devemos ter em conta relativamente à qualidade dos dados:
- Os dados assim que entram no sistema já estão desactualizados
- A conversão de dados é um dos maiores problemas de qualidade de dados
- Convencer os responsáveis que a qualidade de dados é um problema é um desafio.
- Tem sempre de haver num€ros para se poder fundamentar um projecto de DQ
- O projecto de DQ tem de ser um projecto global, envolvendo TODA a empresa.
- Nada se compara a uma validação dos dados logo no seu input. Todos os projectos posteriores de ETL vão ter sempre resultados muito inferiores.
- A chave para termos os melhores dados é pensarmos que os dados nunca estão tão bons como pensamos.
- Não existe perfeição, não existe 100% de dados correctos, mas podemos ficar perto.
- Quem é responsável pela qualidade dos dados na empresa? O Marketing? As Vendas? Os Serviços ao Cliente? O departamento de TI's? Nenhum dos anteriores? Deve haver sempre um responsável e quanto mais alto esse responsável estiver dentro da hierarquia da empresa melhor.
- Todo o "lixo" que entrar, vai ser "lixo" que vai para a rua. O envio desse "lixo" tem custos. O ideal é ter um filtro na entrada dos dados que faça a limpeza desses dados para evitar a entrada do "lixo".

Para haver sucesso num processo de CRM, antes têm de existir fundações fortes. E quais são as fundações de qualquer projecto de CRM? Os dados.

Se os dados não estiverem em condições, não estiverem normalizados e especialmente deduplicados será muito difícil que qualquer CRM tenha sucesso. Se o mesmo individuo tiver mais que um registo, o que vai acontecer é que há tantas possibilidades de haver problemas, que o mais certo é mais tarde ou mais cedo um deles poder vir a acontecer.

Se por exemplo, num envio de email esse individuo fizer o pedido de remoção do envio de emails, essa remoção é executada num dos registos, mas pode ser enviado posteriormente de outro registo, mesmo que o email não seja o mesmo, fica sempre uma má imagem para a empresa. O mesmo se pode passar caso esse cliente peça para alterar por exemplo uma morada. A alteração seria feita apenas num registos e continuariam a ser enviadas comunicações para a anterior morada em outro(s) registo(s) que possam existir. Estes são apenas 2 pequenos exemplos de coisas que podem correr mal por haver registos duplicados.

Tal como mostrei anteriormente num video, é possível manter a qualidade de dados em tempo real, entre outros ambientes, em SAP(R). Estas aplicações que se podem ver em funcionamento no video, são ferramentas certificadas, tendo sido as primeiras a nível mundial a terem esta distinção. A integração destas ferramentas permite que em tempo real, no momento mais importante, ou seja logo na criação do registo, se possa fazer a normalização e deduplicação, conseguindo-se com isto resultados que ficam muito acima de qualquer tratamento batch que se possa fazer posteriormente. Qualquer duvida que exista pode ser imediatamente esclarecida com o interluctor, coisa que à posteriori será sempre muito difícil.

Se o SAP não tiver tido alterações à sua estrutura, quer em termos visuais, quer em termos de estrutura de Base de Dados, esta instalação é o que se pode considerar plug & play. Caso hajam alterações, logicamente que é possível fazer essas adaptações, mas nesse caso logicamente o tempo de integração já não será de um dia para o outro, mas certamente em poucos dias é possível ter a solução em funcionamento.

Cloud, nuvem, ASP, SaaS, Software como Serviço e muitas outras designações que se vão ouvindo para definir o mesmo conceito. O conceito poderemos definir de forma muito simples como o aluguer de um software sempre via internet.

Teoricamente em termos de vantagens é uma relação win-win. O comprador tem como vantagens não necessitar de fazer a manutenção do sistema, não necessitar de se preocupar com os upgrades e tem ainda a vantagem crucial, que é o baixo custo de investimento inicial. Existe ainda a vantagem de que o investimento total fica sempre muito aquém, em caso de uma utilização moderada, do preço total da compra da aplicação. Existem ainda muitas outras vantagens, como por exemplo poder ter sempre um controle sobre os custos, ter acesso imediato a actualizações/alterações, serem sempre soluções flexíveis e evolutivas.

Por outro lado, para o fornecedor, a principal vantagem é poder chegar a mercados que de outra forma lhe estariam inacessíveis.

No caso da qualidade de dados é possível aceder aos processos de normalização de dados, falados anteriormente via SaaS. Em vez de aceder ao servidor local para poder normalizar a morada, com o SaaS esta normalização vai ser efectuada num servidor via web. Esta possibilidade está disponível, e pode ser uma solução não apenas para clientes que tenham um volume de dados que não justifique a compra das aplicações, mas também para clientes que tenham moradas estrangeiras em numero mais reduzido, mas que pretendam fazer a normalização das mesmas. Desta forma localmente fazem a normalização das moradas nacionais e via SaaS fazem a normalização das moradas estrangeiras. Neste serviço podem ser incluídas as coordenadas geográficas.

Por vezes quando se está a fazer comunicação B2C (business-to-consumer) o que deveria ser feito realmente era comunicação B2H (business-to-household).

O dinheiro que se gasta desnecessariamente sempre que é feita uma comunicação offline em criatividade, produção, handling e portes, em material que vai duplicado e triplicado para a mesma casa é um valor que todas as empresas deveriam ter em consideração. A estes custos ainda podemos juntar os devolvidos por moradas mal endereçadas por falta de um software que faça a normalização dos dados.

Com a existência de uma chave de household ficamos com a possibilidade de fazer envios, personalizados segundo o target que pretendemos. Se tivermos uma peça que será dirigida apenas às mulheres de uma casa, podemos assim evitar fazer o envio da peça para mãe e filha que constem da nossa BD, mas apenas para aquela que mais se adequar à peça a enviar.

A deduplicação feita por household não é fácil de executar, encontramos inúmeras dificuldades, das quais destaco, households que são constituídos por indivíduos com nomes de família diferentes, a existência de moradas que podem ser moradas de trabalho ou residências partilhadas.

Estão cada vez mais na voga as aplicações de BI, mas para que elas vinguem têm de ter boa informação.

Como podemos dizer que a informação da sua empresa é boa? Aqui ficam uma série de perguntas, que caso possa responder afirmativamente a todas as questões, pode acreditar que as suas ferramentas de BI vão fazer a sua função correctamente e certamente que lhe vão ser muitíssimo úteis. As perguntas que devem ser feitas relativamente à informação disponibilizada pelas ferramentas de BI são:
- Conseguimos encontrar o que procuramos?
- Está disponível quando necessitamos?
- Inclui tudo o que necessitamos?
- Conseguimos perceber?
- Está correcta?
- Podemos confiar?
- Podemos usar?
Muitas vezes chegamos à conclusão que a informação não é boa e ouvimos queixas, causa conflitos, perdas de tempo, custos elevados e fraco nível de decisão.

“90% dos gestores de topo sentem que não têm a informação necessária para decisões críticas de negócio; 50% deles têm medo que estejam a tomar decisões pouco acertadas devido a isso” Economist Intelligence Unit.

Mais uma vez tudo isto se resume à qualidade dos dados. Embora muitas vezes o que se ouve seja "deitem tudo fora e comecem de novo", isso não é de todo a solução porque caso não estejam incorporadas na empresa medidas que possam assegurar a qualidade dos dados, o que rapidamente vai acontecer à nova base de dados é ficar precisamente com os mesmos problemas que a anterior.

O projecto final entregue aos colaboradores da empresa é realmente útil?

Rapidamente todos os departamentos vão poder verificar a utilidade de um projecto destes nas suas rotinas do dia-a-dia. Por vezes, entram tão rapidamente que a dificuldade é ter noção de como as coisas funcionavam antes de o projecto entrar em actividade. Depois de os utilizadores estarem habituados a ter um sistema que os ajuda, cada vez que dão um erro na inserção da morada, ou que lhes permite colocar apenas alguns caracteres e apenas com esses fazer a normalização da morada, rapidamente se habitua e facilmente compreende a utilidade do projecto. Com o tempo vai certamente achar que o sistema é imprescindível para o dia-a-dia.

Quais são os limites de tolerância que deve ter o projecto?

Por norma todas as aplicações são parametrizáveis e estes limites devem ser tomados em conta, não de uma forma genérica, mas mais uma vez, com a experiencia adquirida. Tal como foi dito nos pontos anteriores todas as BD's são únicas e como tal têm de ter tratamentos diferenciados. Imaginemos que temos uma BD na qual temos uma deduplicação já testada e experimentada, em que o valor de match tem um valor ideal. Mas entretanto foi criado mais um campo que ajuda na deduplicação dos registos, como tal deveremos mudar os limites para termos a certeza que os duplicados são encontrados.

O mesmo se passa relativamente aos parâmetros dos softwares real time. Ao longo do tempo poder-se-á verificar que é necessário fazer acertos porque os utilizadores por exemplo usam mais uma variável que outras para fazer pesquisas. Como tal temos de na parametrização evidenciar essa variável para que os resultados sejam totalmente satisfatórios. Com isto apenas se demonstra que embora os limites devam existir, existe com estas ferramentas sempre a possibilidade de fazer afinações.

Quem devem ser os intervenientes num processo destes?

No final do projecto, toda a empresa deve ter participado no processo porque tal como foi dito, isto afecta todos os departamentos da empresa sem excepção. Numa fase inicial apenas o departamento de informática tem um maior envolvimento no projecto, mas numa fase posterior todos os departamentos são chamados a participar, especialmente se forem colocados a funcionar os softwares que funcionam em real time. Nesta fase todos os colaboradores da empresa que tenham interacção com os dados vão ser chamados a normalizar os dados. Este processo vai apenas simplificar e em muitos casos permitir poupar tempo nas rotinas de introdução/ alteração de dados.

Mesmo que existam vícios de introdução de dados, o que vai acontecer no final é que todas os colaboradores da empresa sem excepção, vão colocar os dados da mesma forma no sistema.

No link podem tentar colocar alguns dados de formas diferentes e como se pode ver no final o resultado é sempre o mesmo.

Quanto tempo demora a ter um projecto destes em funcionamento?

O tempo de implementação de um projecto de qualidade de dados depende de muitos factores: da quantidade de registos existentes, dos sistemas existentes (SO e SGBD), da qualidade actual da BD. Tudo isto são factores que podem interferir no tempo de implementação do projecto de qualidade d e dados.

Vamos então por partes. Relativamente à quantidade de registos existentes, como facilmente se compreende é totalmente diferente normalizar 5.000 registos que normalizar 5.000.000 de registos, não apenas em termos de tempos de processamento máquina, como em termos de tempos de verificação dos resultados e respectivos acertos que sejam necessários efectuar. Especialmente em termos de deduplicação. Todas as BD’s são diferentes e como tal têm de ser efectuados acertos. Não existe nenhuma fórmula mágica que sirva para todas as bd’s e estes acertos, são dos processos mais melindrosos dentro de qualquer projecto de qualidade de dados. Pode ser a diferença entre, ter uma base de dados em que se misturaram clientes que nada têm a ver um com o outro ou então onde ficaram muitos duplicados por encontrar.

Quem já alguma vez tentou retirar duplicados de uma base de dados sabe a dificuldade que esse processo acarreta, porque muitas vezes mesmo estando a olhar para dois registos parecidos, não conseguimos dizer se são duplicados ou não. Fazer isto de forma automática, aumenta a dificuldade. Como tal, apenas com técnicos altamente experimentados conseguimos ter os melhores resultados num processo tão sensivel.

Qual é o budget necessário?

Tal como referido no ponto anterior a solução depende muito da quantidade de dados existente. Existem soluções para todos os budgets. Quanto maior a quantidade de dados, maior será a utilidade das ferramentas que funcionam real time.

Embora existam outras possibilidades, a possibilidade de se fazerem limpezas de dados com alguma regularidade, existem ainda os serviços SAAS, que começam agora a ganhar força, e que permitem que se tenha uma solução a preço reduzido.

Depois logicamente e para organizações de maior dimensão, existem as ferramentas que funcionando em real time permitem que se tenham dados com muita qualidade a todo o momento, por um custo por registo muito bom.

O que vamos fornecer no final aos nossos colaboradores? O que vão ganhar com isto?

O que se vai executar numa fase inicial será a normalização/deduplicação de todos os dados para que os dados passem a ter consistência. Enquanto este processo se desenvolve deverá ser instalado um sistema online que faça a normalização e deduplicação aquando da inserção dos registos para que estes se mantenham sempre com qualidade. Esta abordagem é uma abordagem que não é muito comum no mercado, embora seja a mais avançada. Tem como base ferramentas hi-tec, e que não estão muito divulgadas no nosso mercado. Com estas ferramentas os colaboradores vão ter do seu lado ferramentas que os ajudam no seu dia a dia.

Quantos de nós não tivemos de pedir ao nosso interlocutor para repetir uma morada, porque simplesmente não estávamos a conseguir entender o que estava a ser dito. Com estas ferramentas que aqui podem ser testadas, isso deixa de ser um problema.

Com isto os nossos colaboradores ganham tempo, ganham em imagem, porque se no final ainda conseguirem dizer ao utilizador por exemplo o seu CP7, isso mostra profissionalismo.

Ganham igualmente se tiverem o modulo de georeferenciação, quando tiverem de ir para a rua e não necessitarem de andar a perguntar onde fica a rua, uma vez que já levam as coordenadas geográficas no GPS, ou antes de saírem já viram como chegar ao destino.

O procedimento tradicional nestes casos, consiste em executar processo de qualidade de dados (normalização e deduplicação) e passados uns meses, voltar a correr esse processo. Este “ciclo” tem como desvantagens os custos que ficam associados, a deterioração dos dados ao longo do tempo até à normalização seguinte.

Porque vamos fazer este projecto? Este projecto é realmente necessário?

A resposta ao porquê, já foi anteriormente respondida no post inicial deste blog, mas é sempre bom reforçar argumentos. Tal como foi dito anteriormente os dados são as fundações de qualquer empresa. Não tendo dados de qualidade, os custos operacionais podem ser enormes, embora ninguém saiba muito bem quantificar o real valor destes custos nas respectivas empresas.

Por norma estes custos estão dispersos pelos diferentes departamentos da empresa. Se pensarmos em termos do departamento de informática, passam horas incontáveis a tentar resolver problemas de integridade de dados, porque por exemplo, quando lhes é pedida uma contagem simples ao número de clientes de uma determinada zona. Como não têm capacidade imediata para dar resposta, vão verificar, muitas vezes manualmente e sem ferramentas adequadas, os registos que não têm distrito, concelho ou freguesia associada, ou até quem sabe um código postal de 7 dígitos de forma a poder cruzar com a tabela que faz a associação com os respectivos vendedores. Este é apenas um pequeno exemplo.

Depois no departamento de distribuição, por não terem as moradas normalizadas, nem com coordenadas geográficas, os carros têm de parar para pedir informações porque a rua como está escrita, não aparece no GPS, ou quem sabe andarem perdidos com os respectivos custos associados.

No departamento de Marketing, não se contabilizaram as devoluções que existem relativas à última campanha. Que têm associados custos não apenas de portes de correio, mas de criatividade da peça, desenvolvimento, impressão e envelopagem. Tudo isto são custos que se deveriam associar a cada uma daquelas peças que vieram devolvidas. Juntando a isto, temos ainda os clientes que receberam peças em duplicado ou triplicado, com os custos de imagem que isso implica.

No departamento de vendas por vezes podem não ter uma real noção dos gostos/necessidades dos respectivos clientes porque as vendas estão dispersas por mais que um registo. Como tal perdem oportunidades de vendas apenas porque o vendedor ao olhar para a ficha do cliente não tinha nesse registo a informação que ele era consumidor de um produto que por acaso nessa altura estava em promoção, de entre outros que o vendedor destacou.

Estas são apenas algumas das implicações que a falta de qualidade de dados pode trazer para dentro da organização, sendo que contabilizar todos estes valor é quase uma missão impossível.

Ainda dentro da remoção/alocação de duplicados, falada no post Limpeza de dados, existe muito mais que dizer. São inúmeras as formas de encontrar duplicados, sendo a mais comum por indivíduo. Mas podemos encontrar duplicados, não apenas por indivíduo, mas por domicílio (household), por edificação, por família, e muitos outras formas que sejam interessantes para os fins pretendidos, isto quando estamos a falar de bases de dados B2C (business to consumer). Se formos para as BD’s B2B (business to business) podemos detectar duplicados por empresa, por departamento, enfim um sem número de possibilidades.

Por norma estes softwares o que fazem é a criação de chaves que devem ficar guardadas em BD para serem usadas sempre que necessárias. Por exemplo já fizemos a deduplicação para encontrar os duplicados por domicílio, e vamos ter uma acção de Marketing na empresa que vai envolver uma peça que é extremamente cara, como tal, apenas queremos enviar uma peça para cada domicílio, para que os custos não sejam tão elevados. Indo buscar a chave que está guardada em BD, permite o envio apenas para um dos indivíduos desse domicílio, sendo que a escolha de para qual vai ser feito o envio pode ser efectuada com a ajuda por exemplo da data de nascimento. Vamos apenas enviar para o mais velho.

Esta e muitas outras possibilidades são assim facilmente executadas, sem necessidade de ter preocupações extremas antes de cada campanha.