Run Zingg on Spark in Google Cloud and read from and write to BigQuery directly. Your data stays in your project, and resolved entities with a persistent ZINGG_ID land back in BigQuery for analytics, AI and activation.
Results are written back to BigQuery.Zingg reads source tables from BigQuery and writes resolved entities back, through the Spark BigQuery connector.
Zingg authenticates with your service account and runs in your own Google Cloud project.
Blocking learned from your labels keeps comparisons low as your data grows. How Zingg scales
A set of notebooks on the Zingg Python API that take you from setup to labeling training pairs, model documentation, and training and matching on Spark, with BigQuery as source and sink through the Spark BigQuery connector.
Zingg notebooksIncremental flow, persistent ZINGG_IDs, explainability and model diff, plus support from the builders of Zingg.
Talk to usA persistent, global identifier for every resolved entity, so every team and agent joins on the same key.
Learn moreMatch only new, updated and deleted records against the clusters already resolved. IDs persist between runs.
Learn moreSee the evidence behind every match, so you can explain results to business users.
Learn moreConfidently add new signals, update configuration and deploy models in production.
Learn moreYes. Zingg reads from and writes to BigQuery through the Spark BigQuery connector. Writing uses a temporary Cloud Storage bucket.
No. Zingg runs on Spark in your own project and writes results back to BigQuery.
With a Google Cloud service account key that you point Zingg to.
The incremental flow, persistent ZINGG_IDs, explainability, model diff and enterprise support.
Run Zingg on your own Google Cloud project, with BigQuery in and out.