›
›
›
›
Clay data enrichment: how to build enrichment waterfalls
Clay data enrichment: how to build enrichment waterfalls
Clay data enrichment: how to build enrichment waterfalls
Clay data enrichment: how to build enrichment waterfalls
Clay data enrichment: how to build enrichment waterfalls
Clay data enrichment: how to build enrichment waterfalls
Author
Aljaz Peklaj
Two thousand accounts sit in your Clay table, half of them missing a headcount, and the sequence you're about to launch will bounce on every contact you can't verify.
Enrichment is a routing decision. A populated cell doesn't qualify a contact. Explicit rules do.
Field design drives the bill. Must-have fields and conditional fields have very different cost profiles.
Coverage numbers hide the trade-off. The provider with the most populated cells is often the least accurate one.
Governance sits at field level. A compliant provider doesn't make a compliant workflow.
Audit 200 records before you scale. Baseline the bounce rate first, then let the numbers decide.
The tool isn't the problem. The problem is that many treat enrichment as a fill-the-blanks exercise and skip the part where someone decides which records are safe to send to. Below is how I build that decision into a Clay workflow, where the credits go, and which records never leave the table.
Table of Contents
What Clay data enrichment adds to a lead record
A thin record forces a guess, and guesses get expensive at volume. Enrichment is the work of adding or refreshing attributes on a record: verified work email, phone number, headcount, industry, revenue band, installed technology, hiring activity, funding events, and job titles.
The Sacra profile of Clay traces how that work moved from single-source contact databases toward a marketplace connecting workflows with more than 150 data providers. The documented Intercom example shows the scale this reaches: in one month, Intercom sourced more than 4,000 accounts and enriched 21,000 contacts across firmographics, job postings, technology signals and contact attributes, which works out to roughly 5.25 enriched contacts per sourced account.
That ratio is the part worth copying. Account-level research and person-level enrichment belong in the same table, because the account decides whether you care and the person decides whether you can reach anyone.
Every field exists to route the record somewhere: into the sequence, into a review queue, or out of the table. A provider can fill every cell and still leave you guessing, since a low-confidence value behaves like an empty one unless you write the rule that handles it. Ask what each column decides before you ask how to fill it.
Firmographics answer fit. Technographics answer relevance. Hiring and funding answer timing. A record with only a name and an email answers none of those, so a rep opens it, guesses, and writes something generic.
What each enriched field actually decides
Field | Source type | Pipeline decision it supports |
|---|---|---|
Verified work email | Waterfall across email providers | Whether the contact is safe to send to |
Headcount and industry | Firmographic provider | Whether the account fits the ICP |
Installed technology | Technographic provider | Whether the account matches your integration needs |
Job postings and hiring activity | Hiring data source | When to start outreach |
Funding events | Funding data provider | Budget and timing signal |
Role and seniority | Person-level provider | Whether the buyer holds decision authority |
Personalization notes | AI research (Claygent) | Opening line, only when the claim has a cited source |
Name the three fields your next campaign depends on, then check whether the rows in your table carry them with a source attached. A row holding a value with no confidence signal behind it goes to review, not to the sequencer. Seven populated columns often reduce to the two that route the record.
How the waterfall calls providers in order
Take a single field: a work email for a US SaaS buyer list. Clay's waterfall documentation describes the mechanic precisely. Providers run sequentially for that one data point, and the chain stops once a valid result comes back, rather than sending the same lookup to every connected source.
That matters commercially. Every miss is a paid lookup, so the order you set determines which source wins the field and how many provider calls you buy before a match appears.
Here's the build I'd run for that list.
Name the field and its required input. An email lookup needs first name, last name and company domain. A phone lookup usually needs a LinkedIn profile URL. Partial inputs are the most common reason a provider returns nothing, and you still pay for the attempt.
Add the enrichment and set the order. Select Add enrichment, choose the waterfall, then reorder, add, delete or skip providers in the sequence panel. Start with whichever source covers your market best, not whichever vendor markets loudest.
Skip providers that can't serve the market. If a provider has thin coverage in a country or seniority band, remove it from that waterfall. Leaving it in spends lookups to learn what you already knew.
Write the validation rule. Accept only results marked valid, and let a miss or an invalid result fall through to the next provider. Without a stopping rule the chain keeps spending after it has a usable answer.
Output the winning provider and hide the middle columns. Keep a column that names the provider for each field. Hide the individual provider columns so the working table stays readable, but keep that name for the quality review later.
Add the run condition and turn on auto-update. Enrich only rows that already pass your ICP filter, so you never pay to enrich an account you wouldn't contact. Auto-update refreshes the field when a company or a person changes.
The end state is mundane and specific: enriched rows sync to HubSpot, then into Instantly or Smartlead for sequencing.
Working rule: a row without a provider name, a validation flag and a timestamp isn't enriched. It's guessed at.
A healthy table shows all three on every accepted row. When a field goes wrong six weeks later, that trio tells you whether the provider slipped, the refresh window lapsed, or the input was bad from the start.
What enrichment costs and how to budget credits
Clay meters two different things, and conflating them is why budgets surprise people. Actions measure work performed inside the workflow. Data Credits pay for information or AI supplied by third-party vendors in the marketplace, and Clay's university documentation puts Actions at a few tenths of a penny each and Data Credits at a few pennies, with the credit price varying by data type.
Each enrichment execution consumes one Action, and net-new third-party data generally consumes Data Credits unless you use free data or supply a private API key (Clay's FAQ on Actions and Data Credits). The practical split is simple: orchestration is cheap, answers are not.
Now the number that governs everything. A fully enriched person or company record typically costs 6 to 20 Data Credits when the workflow includes company and person profiles, email, phone and custom AI enrichments, per Clay's plans and billing documentation. That range is wide enough to break a budget on its own, and the same plan math gives these working tiers:
Plan | Monthly price from | Actions | Data credits | Fits teams enriching |
|---|---|---|---|---|
Starter plan | $185 | 15,000 | 2,500 to 10,000 | About 1,000 to 10,000 records per month |
Higher plan | $495 | 40,000 | 6,000 to 100,000 | 10,000 or more records per month |
Run the math on your own field list. At 6 credits per record, 2,500 credits cover about 416 fully enriched records. At 20 credits, the same 2,500 credits cover 125. At 10,000 credits you get roughly 1,666 records on the lean design or 500 on the heavy one.
That is why enrichment quality is a routing decision before it is a coverage number. A record that earns phone and AI research should already have passed fit, source validation and owner assignment; otherwise the expensive fields are being spent on rows sales will never touch.
Budget credits in this order
Forecast records per month, not campaigns per quarter. Record volume is what consumes credits.
Split fields into must-have and conditional. Verified work email and role are must-have. Phone, funding and AI research are conditional.
Run cheap firmographic and ICP filters first, so paid contact lookups only touch accounts that pass fit.
Gate the expensive fields behind routing rules. Phone and AI research run only on rows already assigned to a rep.
Set workbook or workflow credit limits before any large run. A cap set after the run is a bill, not a control.
Track cost per accepted contact. Cost per attempted row flatters a broad waterfall that mostly returns uncertainty.
Clay's pricing FAQ also publishes a lower entry point from $149 per month and a free trial of 1,000 credits for 14 days. Read that as a separate entry tier alongside the $185 and $495 plans in the table, then budget from whichever tier's Actions and Data Credits match your record math rather than the headline price.
One lever changes the shape of the bill. A private provider API key removes marketplace Data Credits on those lookups while the workflow still consumes Actions, so the marginal cost falls without disappearing. If you already pay for a provider you trust, that is the cheapest way to keep using it inside the table. For a side-by-side read on the tiers against monthly record volume, this breakdown of Clay pricing goes deeper than the plan page.
Measuring enrichment quality beyond coverage
More populated cells can lower pipeline quality, and the vendor comparisons show why. Clay's CRM enrichment guide reports that Hunter hit 97.15% accuracy on work emails but returned a verdict for only about half of records, while Findymail reached 90.26% coverage with lower accuracy.
Read that as a routing problem, not a sourcing problem. A waterfall that fills 90% of a column with addresses nobody verified has moved the failure downstream, where it shows up as bounces and a damaged sending domain instead of a blank cell.
The cost of that failure is not abstract. A 2026 compilation citing Gartner and MIT Sloan Management Review puts poor data quality at roughly $12.9 million per year for an affected organization, with revenue losses reaching 15% to 25% (data enrichment statistics). The same compilation reports that 47% of newly created records contain a critical error and that B2B databases decay by about 22.5% annually.
That decay figure is the one I plan around. Without a refresh process, nearly a quarter of a database's usable information goes stale over a year, which means enrichment is a recurring operation, not a one-time list build.
Five tests before a record reaches a rep
Test | What you measure | Fail state |
|---|---|---|
Coverage | Share of rows with a value for that field | An empty cell is not a pass |
Validity | Valid versus unknown or catch-all | Unknown or catch-all becomes do not contact |
Freshness | Days since collection against the refresh window | Older than the window goes back through the waterfall |
Confidence | Named provider and score versus the threshold | Below threshold goes to review, not outbound |
Business usefulness | Whether the field changes ICP, timing or buyer | A populated but unused field is dropped from the run |
Score each test by segment, geography, seniority and source. A waterfall that scores well on US mid-market SaaS can fail badly on manufacturing in DACH, and you'll only see it if you split the numbers.
Validity is the test teams skip most often, and it's the one that decides whether a send happens at all. If you're picking the verifier behind that flag, this comparison of email verification tools covers how each one handles catch-all and unknown results.
Unknown and catch-all emails never enter a sequence. Give them a do-not-contact state and leave them there until a verifier returns something definitive.
Records under your confidence threshold belong in a review queue, not in outbound. That's the same logic Grou uses on fit rules so sales doesn't spend time on wrong leads, and it's the reason a smaller accepted list beats a large uncertain one every time.
One caution on AI-generated fields. No independent benchmark of Claygent's accuracy or hallucination rate exists, so treat a scraped value proposition or an inferred intent score as a hypothesis. It needs a cited source before it becomes an opening line.
Here's the build in the interface, if you want to see the mechanics before wiring your own.
The other half of quality measurement is downstream. Track bounce rate, positive-reply rate, meeting rate and disqualification rate by provider and by segment. A provider that adds 8 points of coverage and 3 points of bounce has told you where it belongs.
Governing personal data across global outbound markets
A provider's compliance page protects the provider. Your workflow needs its own paper trail. Under the standard controller/processor split, the customer acts as controller, Clay acts as processor, and individual integrations can carry their own privacy terms. The legal exposure sits with you, not with the vendor whose badge is on the invoice.
Four operational questions land on the customer's desk. Which lawful basis applies in each target market. How to document the source and purpose of a personal contact field. How to honor a deletion or objection request when the record passed through five chained providers. Who answers when a provider's data turns out to be wrong.
The sharp version: a GDPR-compliant provider does not make a compliant workflow. Compliance lives in provenance, retention, refresh intervals, suppression lists, human review and downstream use. Any one of those can fail while every vendor on the invoice is certified. The test I'd apply is simple: could you produce the paper trail for one contact in under five minutes?
Build a control matrix before the next campaign
Set the matrix up per market, covering the EU and EEA, the UK, the US and any other region in your target list. Give each market four columns: lawful basis, retention period, refresh interval, and suppression list owner. One row per market, one owner per row, reviewed before a sequence goes live.
Then log every enriched field, not every record. The log needs five values:
Source URL, so you can show where a personal field came from.
Collection date, so freshness is auditable rather than assumed.
Confidence score, so a reviewer sees what the system thought of its own answer.
Lawful-purpose note, one line on why this field exists in this workflow.
Deletion status, updated when someone objects or asks to be removed.
A field with no logged source gets the same treatment as a field with a low confidence score. It routes to review, not to outbound, and it stays there until someone can defend it.
Human review goes on top for AI-scraped websites and personal social profiles. A model that reads a founder's LinkedIn post and drafts a line about it is producing a claim, not a fact, and the claim needs a reviewer before it reaches a sequence.
Grou documents its ICP, targeting criteria, sequences and fit rules so a client's team has full visibility and can take the system over or build on it. The data layer deserves the same standard.
A control matrix you can hand to counsel in ten minutes beats a compliance page you can't audit at all.
Treat this as an operating framework, not legal advice. Have counsel sign off on the matrix for each market before you scale sends into it. For the cold email side of the same problem, the GDPR cold email operator guide covers the sequence-level controls that sit on top of this data layer.
Clay versus single databases and manual research
Clay wins for teams enriching across several markets or field types. A single database wins for a stable ICP in one market when nobody on your team will maintain workflows. That's the verdict, and the rest of this section is the reasoning behind it.
Clay doesn't own a proprietary database. It sells orchestration across a marketplace of external providers, which is why provider selection and call order end up being go-to-market decisions rather than technical settings (Clay's FAQ on which actions cost credits). In manufacturing, pharma, legal tech or iGaming, coverage depends entirely on who you call and in what order.
Approach | How records get filled | Best when | Main risk |
|---|---|---|---|
Clay waterfall | Several providers called in order, stopping at the first valid result | Several markets or field types, with someone who maintains workflows | Quality and cost depend on provider order and rules |
Single database (ZoomInfo or Apollo) | One vendor's dataset per lookup | One market, stable ICP, no workflow owner | Gaps wherever that vendor is thin, with no fallback |
Clay with your own API keys | Your existing subscriptions run inside Clay | You already pay for providers you trust | Still needs per-provider governance and credit tracking |
Manual research with AI prompts | One account at a time | Under 100 accounts a month | Slow, hard to audit and does not scale |
The coverage claim floating around deserves the label it needs: it's vendor-reported. Clay states that an enterprise customer raised enrichment coverage from 30% with ZoomInfo to 80% with Clay while cutting cost from about $0.25 to less than $0.01 per enrichment (Clay's FAQ). Take it as a customer claim, not a benchmark you can assume for your own list.
Durability matters too when you're standardizing a workflow on one platform. Clay reports raising $115 million in Series D funding at a $7.1 billion valuation after fourfold revenue growth in 2025 (Clay's blog). A vendor that can fund its marketplace keeps adding providers. It doesn't guarantee any single provider is good in your market.
Where the answer flips
Two situations change my recommendation. If your ICP is one country, one seniority band and one industry, and no one on the team wants to own a waterfall, a single database returns more usable records per hour of effort. If you're enriching fewer than 100 accounts a month, a person with a research prompt and a verification step is cheaper than a platform.
Everything in between rewards orchestration. That's when you start comparing individual vendors on regional strength, which is a separate question from platform choice, and this comparison of Apollo versus Cognism is useful for the European coverage decision specifically.
For the provider-level view, this roundup of B2B data providers covers where each one is strong.
Run a 200-record enrichment audit this week
Stop tuning the waterfall by feel. Two hundred records will tell you more than a month of guessing, and the test costs less than a lunch.
Export 200 records across two segments. Pick one segment you convert well and one you lose. Same waterfall, same fields, two populations.
Run the waterfall you use today, and add a column naming the provider for each field. That column is the whole audit. Without it you're measuring the waterfall, not the sources inside it.
Have a person check 50 records against a source you trust. Open the company site, check the person's role, verify the email pattern. Fifty is enough to see a provider drifting.
Calculate coverage, validity and cost per accepted contact for each segment and each provider. Split the numbers, not the average. A blended figure hides the provider that's failing in one market.
Set the pass rule before you send anything. The waterfall passes only if accepted records beat your baseline on bounce rate without raising cost per accepted contact. Decide that now, while you're still unbiased.
Send accepted and flagged records into separate sequences. Compare bounce rate and reply rate after two weeks. Flagged records that perform inside a tolerance band are your evidence for loosening a rule. Flagged records that bounce confirm it.
If the audit shows your gap sits at account level rather than contact level, this account research workflow walks through the research steps that feed the same table before you spend a credit on contact data.
The order matters. Many teams run the send first and the audit after, which means the audit is really a post-mortem on a damaged domain.
If you're not sure whether the bottleneck is your data, your targeting or your messaging, the two-minute pipeline quiz shows where your pipeline breaks and which service fits best.
Grou has built B2B pipeline systems for more than 50 companies across iGaming, SaaS, manufacturing, legal tech and pharma. Every workflow is documented, so your team can audit it, change it, or take it over entirely.
If your table is full of rows nobody has verified, that's a pipeline problem before it's a data problem. Grou builds the enrichment layer, the fit rules and the outbound sequences as one system, so the records that reach a rep are already worth the call. Start at Grou and we'll show you where your current list is leaking meetings.
Two thousand accounts sit in your Clay table, half of them missing a headcount, and the sequence you're about to launch will bounce on every contact you can't verify.
Enrichment is a routing decision. A populated cell doesn't qualify a contact. Explicit rules do.
Field design drives the bill. Must-have fields and conditional fields have very different cost profiles.
Coverage numbers hide the trade-off. The provider with the most populated cells is often the least accurate one.
Governance sits at field level. A compliant provider doesn't make a compliant workflow.
Audit 200 records before you scale. Baseline the bounce rate first, then let the numbers decide.
The tool isn't the problem. The problem is that many treat enrichment as a fill-the-blanks exercise and skip the part where someone decides which records are safe to send to. Below is how I build that decision into a Clay workflow, where the credits go, and which records never leave the table.
Table of Contents
What Clay data enrichment adds to a lead record
A thin record forces a guess, and guesses get expensive at volume. Enrichment is the work of adding or refreshing attributes on a record: verified work email, phone number, headcount, industry, revenue band, installed technology, hiring activity, funding events, and job titles.
The Sacra profile of Clay traces how that work moved from single-source contact databases toward a marketplace connecting workflows with more than 150 data providers. The documented Intercom example shows the scale this reaches: in one month, Intercom sourced more than 4,000 accounts and enriched 21,000 contacts across firmographics, job postings, technology signals and contact attributes, which works out to roughly 5.25 enriched contacts per sourced account.
That ratio is the part worth copying. Account-level research and person-level enrichment belong in the same table, because the account decides whether you care and the person decides whether you can reach anyone.
Every field exists to route the record somewhere: into the sequence, into a review queue, or out of the table. A provider can fill every cell and still leave you guessing, since a low-confidence value behaves like an empty one unless you write the rule that handles it. Ask what each column decides before you ask how to fill it.
Firmographics answer fit. Technographics answer relevance. Hiring and funding answer timing. A record with only a name and an email answers none of those, so a rep opens it, guesses, and writes something generic.
What each enriched field actually decides
Field | Source type | Pipeline decision it supports |
|---|---|---|
Verified work email | Waterfall across email providers | Whether the contact is safe to send to |
Headcount and industry | Firmographic provider | Whether the account fits the ICP |
Installed technology | Technographic provider | Whether the account matches your integration needs |
Job postings and hiring activity | Hiring data source | When to start outreach |
Funding events | Funding data provider | Budget and timing signal |
Role and seniority | Person-level provider | Whether the buyer holds decision authority |
Personalization notes | AI research (Claygent) | Opening line, only when the claim has a cited source |
Name the three fields your next campaign depends on, then check whether the rows in your table carry them with a source attached. A row holding a value with no confidence signal behind it goes to review, not to the sequencer. Seven populated columns often reduce to the two that route the record.
How the waterfall calls providers in order
Take a single field: a work email for a US SaaS buyer list. Clay's waterfall documentation describes the mechanic precisely. Providers run sequentially for that one data point, and the chain stops once a valid result comes back, rather than sending the same lookup to every connected source.
That matters commercially. Every miss is a paid lookup, so the order you set determines which source wins the field and how many provider calls you buy before a match appears.
Here's the build I'd run for that list.
Name the field and its required input. An email lookup needs first name, last name and company domain. A phone lookup usually needs a LinkedIn profile URL. Partial inputs are the most common reason a provider returns nothing, and you still pay for the attempt.
Add the enrichment and set the order. Select Add enrichment, choose the waterfall, then reorder, add, delete or skip providers in the sequence panel. Start with whichever source covers your market best, not whichever vendor markets loudest.
Skip providers that can't serve the market. If a provider has thin coverage in a country or seniority band, remove it from that waterfall. Leaving it in spends lookups to learn what you already knew.
Write the validation rule. Accept only results marked valid, and let a miss or an invalid result fall through to the next provider. Without a stopping rule the chain keeps spending after it has a usable answer.
Output the winning provider and hide the middle columns. Keep a column that names the provider for each field. Hide the individual provider columns so the working table stays readable, but keep that name for the quality review later.
Add the run condition and turn on auto-update. Enrich only rows that already pass your ICP filter, so you never pay to enrich an account you wouldn't contact. Auto-update refreshes the field when a company or a person changes.
The end state is mundane and specific: enriched rows sync to HubSpot, then into Instantly or Smartlead for sequencing.
Working rule: a row without a provider name, a validation flag and a timestamp isn't enriched. It's guessed at.
A healthy table shows all three on every accepted row. When a field goes wrong six weeks later, that trio tells you whether the provider slipped, the refresh window lapsed, or the input was bad from the start.
What enrichment costs and how to budget credits
Clay meters two different things, and conflating them is why budgets surprise people. Actions measure work performed inside the workflow. Data Credits pay for information or AI supplied by third-party vendors in the marketplace, and Clay's university documentation puts Actions at a few tenths of a penny each and Data Credits at a few pennies, with the credit price varying by data type.
Each enrichment execution consumes one Action, and net-new third-party data generally consumes Data Credits unless you use free data or supply a private API key (Clay's FAQ on Actions and Data Credits). The practical split is simple: orchestration is cheap, answers are not.
Now the number that governs everything. A fully enriched person or company record typically costs 6 to 20 Data Credits when the workflow includes company and person profiles, email, phone and custom AI enrichments, per Clay's plans and billing documentation. That range is wide enough to break a budget on its own, and the same plan math gives these working tiers:
Plan | Monthly price from | Actions | Data credits | Fits teams enriching |
|---|---|---|---|---|
Starter plan | $185 | 15,000 | 2,500 to 10,000 | About 1,000 to 10,000 records per month |
Higher plan | $495 | 40,000 | 6,000 to 100,000 | 10,000 or more records per month |
Run the math on your own field list. At 6 credits per record, 2,500 credits cover about 416 fully enriched records. At 20 credits, the same 2,500 credits cover 125. At 10,000 credits you get roughly 1,666 records on the lean design or 500 on the heavy one.
That is why enrichment quality is a routing decision before it is a coverage number. A record that earns phone and AI research should already have passed fit, source validation and owner assignment; otherwise the expensive fields are being spent on rows sales will never touch.
Budget credits in this order
Forecast records per month, not campaigns per quarter. Record volume is what consumes credits.
Split fields into must-have and conditional. Verified work email and role are must-have. Phone, funding and AI research are conditional.
Run cheap firmographic and ICP filters first, so paid contact lookups only touch accounts that pass fit.
Gate the expensive fields behind routing rules. Phone and AI research run only on rows already assigned to a rep.
Set workbook or workflow credit limits before any large run. A cap set after the run is a bill, not a control.
Track cost per accepted contact. Cost per attempted row flatters a broad waterfall that mostly returns uncertainty.
Clay's pricing FAQ also publishes a lower entry point from $149 per month and a free trial of 1,000 credits for 14 days. Read that as a separate entry tier alongside the $185 and $495 plans in the table, then budget from whichever tier's Actions and Data Credits match your record math rather than the headline price.
One lever changes the shape of the bill. A private provider API key removes marketplace Data Credits on those lookups while the workflow still consumes Actions, so the marginal cost falls without disappearing. If you already pay for a provider you trust, that is the cheapest way to keep using it inside the table. For a side-by-side read on the tiers against monthly record volume, this breakdown of Clay pricing goes deeper than the plan page.
Measuring enrichment quality beyond coverage
More populated cells can lower pipeline quality, and the vendor comparisons show why. Clay's CRM enrichment guide reports that Hunter hit 97.15% accuracy on work emails but returned a verdict for only about half of records, while Findymail reached 90.26% coverage with lower accuracy.
Read that as a routing problem, not a sourcing problem. A waterfall that fills 90% of a column with addresses nobody verified has moved the failure downstream, where it shows up as bounces and a damaged sending domain instead of a blank cell.
The cost of that failure is not abstract. A 2026 compilation citing Gartner and MIT Sloan Management Review puts poor data quality at roughly $12.9 million per year for an affected organization, with revenue losses reaching 15% to 25% (data enrichment statistics). The same compilation reports that 47% of newly created records contain a critical error and that B2B databases decay by about 22.5% annually.
That decay figure is the one I plan around. Without a refresh process, nearly a quarter of a database's usable information goes stale over a year, which means enrichment is a recurring operation, not a one-time list build.
Five tests before a record reaches a rep
Test | What you measure | Fail state |
|---|---|---|
Coverage | Share of rows with a value for that field | An empty cell is not a pass |
Validity | Valid versus unknown or catch-all | Unknown or catch-all becomes do not contact |
Freshness | Days since collection against the refresh window | Older than the window goes back through the waterfall |
Confidence | Named provider and score versus the threshold | Below threshold goes to review, not outbound |
Business usefulness | Whether the field changes ICP, timing or buyer | A populated but unused field is dropped from the run |
Score each test by segment, geography, seniority and source. A waterfall that scores well on US mid-market SaaS can fail badly on manufacturing in DACH, and you'll only see it if you split the numbers.
Validity is the test teams skip most often, and it's the one that decides whether a send happens at all. If you're picking the verifier behind that flag, this comparison of email verification tools covers how each one handles catch-all and unknown results.
Unknown and catch-all emails never enter a sequence. Give them a do-not-contact state and leave them there until a verifier returns something definitive.
Records under your confidence threshold belong in a review queue, not in outbound. That's the same logic Grou uses on fit rules so sales doesn't spend time on wrong leads, and it's the reason a smaller accepted list beats a large uncertain one every time.
One caution on AI-generated fields. No independent benchmark of Claygent's accuracy or hallucination rate exists, so treat a scraped value proposition or an inferred intent score as a hypothesis. It needs a cited source before it becomes an opening line.
Here's the build in the interface, if you want to see the mechanics before wiring your own.
The other half of quality measurement is downstream. Track bounce rate, positive-reply rate, meeting rate and disqualification rate by provider and by segment. A provider that adds 8 points of coverage and 3 points of bounce has told you where it belongs.
Governing personal data across global outbound markets
A provider's compliance page protects the provider. Your workflow needs its own paper trail. Under the standard controller/processor split, the customer acts as controller, Clay acts as processor, and individual integrations can carry their own privacy terms. The legal exposure sits with you, not with the vendor whose badge is on the invoice.
Four operational questions land on the customer's desk. Which lawful basis applies in each target market. How to document the source and purpose of a personal contact field. How to honor a deletion or objection request when the record passed through five chained providers. Who answers when a provider's data turns out to be wrong.
The sharp version: a GDPR-compliant provider does not make a compliant workflow. Compliance lives in provenance, retention, refresh intervals, suppression lists, human review and downstream use. Any one of those can fail while every vendor on the invoice is certified. The test I'd apply is simple: could you produce the paper trail for one contact in under five minutes?
Build a control matrix before the next campaign
Set the matrix up per market, covering the EU and EEA, the UK, the US and any other region in your target list. Give each market four columns: lawful basis, retention period, refresh interval, and suppression list owner. One row per market, one owner per row, reviewed before a sequence goes live.
Then log every enriched field, not every record. The log needs five values:
Source URL, so you can show where a personal field came from.
Collection date, so freshness is auditable rather than assumed.
Confidence score, so a reviewer sees what the system thought of its own answer.
Lawful-purpose note, one line on why this field exists in this workflow.
Deletion status, updated when someone objects or asks to be removed.
A field with no logged source gets the same treatment as a field with a low confidence score. It routes to review, not to outbound, and it stays there until someone can defend it.
Human review goes on top for AI-scraped websites and personal social profiles. A model that reads a founder's LinkedIn post and drafts a line about it is producing a claim, not a fact, and the claim needs a reviewer before it reaches a sequence.
Grou documents its ICP, targeting criteria, sequences and fit rules so a client's team has full visibility and can take the system over or build on it. The data layer deserves the same standard.
A control matrix you can hand to counsel in ten minutes beats a compliance page you can't audit at all.
Treat this as an operating framework, not legal advice. Have counsel sign off on the matrix for each market before you scale sends into it. For the cold email side of the same problem, the GDPR cold email operator guide covers the sequence-level controls that sit on top of this data layer.
Clay versus single databases and manual research
Clay wins for teams enriching across several markets or field types. A single database wins for a stable ICP in one market when nobody on your team will maintain workflows. That's the verdict, and the rest of this section is the reasoning behind it.
Clay doesn't own a proprietary database. It sells orchestration across a marketplace of external providers, which is why provider selection and call order end up being go-to-market decisions rather than technical settings (Clay's FAQ on which actions cost credits). In manufacturing, pharma, legal tech or iGaming, coverage depends entirely on who you call and in what order.
Approach | How records get filled | Best when | Main risk |
|---|---|---|---|
Clay waterfall | Several providers called in order, stopping at the first valid result | Several markets or field types, with someone who maintains workflows | Quality and cost depend on provider order and rules |
Single database (ZoomInfo or Apollo) | One vendor's dataset per lookup | One market, stable ICP, no workflow owner | Gaps wherever that vendor is thin, with no fallback |
Clay with your own API keys | Your existing subscriptions run inside Clay | You already pay for providers you trust | Still needs per-provider governance and credit tracking |
Manual research with AI prompts | One account at a time | Under 100 accounts a month | Slow, hard to audit and does not scale |
The coverage claim floating around deserves the label it needs: it's vendor-reported. Clay states that an enterprise customer raised enrichment coverage from 30% with ZoomInfo to 80% with Clay while cutting cost from about $0.25 to less than $0.01 per enrichment (Clay's FAQ). Take it as a customer claim, not a benchmark you can assume for your own list.
Durability matters too when you're standardizing a workflow on one platform. Clay reports raising $115 million in Series D funding at a $7.1 billion valuation after fourfold revenue growth in 2025 (Clay's blog). A vendor that can fund its marketplace keeps adding providers. It doesn't guarantee any single provider is good in your market.
Where the answer flips
Two situations change my recommendation. If your ICP is one country, one seniority band and one industry, and no one on the team wants to own a waterfall, a single database returns more usable records per hour of effort. If you're enriching fewer than 100 accounts a month, a person with a research prompt and a verification step is cheaper than a platform.
Everything in between rewards orchestration. That's when you start comparing individual vendors on regional strength, which is a separate question from platform choice, and this comparison of Apollo versus Cognism is useful for the European coverage decision specifically.
For the provider-level view, this roundup of B2B data providers covers where each one is strong.
Run a 200-record enrichment audit this week
Stop tuning the waterfall by feel. Two hundred records will tell you more than a month of guessing, and the test costs less than a lunch.
Export 200 records across two segments. Pick one segment you convert well and one you lose. Same waterfall, same fields, two populations.
Run the waterfall you use today, and add a column naming the provider for each field. That column is the whole audit. Without it you're measuring the waterfall, not the sources inside it.
Have a person check 50 records against a source you trust. Open the company site, check the person's role, verify the email pattern. Fifty is enough to see a provider drifting.
Calculate coverage, validity and cost per accepted contact for each segment and each provider. Split the numbers, not the average. A blended figure hides the provider that's failing in one market.
Set the pass rule before you send anything. The waterfall passes only if accepted records beat your baseline on bounce rate without raising cost per accepted contact. Decide that now, while you're still unbiased.
Send accepted and flagged records into separate sequences. Compare bounce rate and reply rate after two weeks. Flagged records that perform inside a tolerance band are your evidence for loosening a rule. Flagged records that bounce confirm it.
If the audit shows your gap sits at account level rather than contact level, this account research workflow walks through the research steps that feed the same table before you spend a credit on contact data.
The order matters. Many teams run the send first and the audit after, which means the audit is really a post-mortem on a damaged domain.
If you're not sure whether the bottleneck is your data, your targeting or your messaging, the two-minute pipeline quiz shows where your pipeline breaks and which service fits best.
Grou has built B2B pipeline systems for more than 50 companies across iGaming, SaaS, manufacturing, legal tech and pharma. Every workflow is documented, so your team can audit it, change it, or take it over entirely.
If your table is full of rows nobody has verified, that's a pipeline problem before it's a data problem. Grou builds the enrichment layer, the fit rules and the outbound sequences as one system, so the records that reach a rep are already worth the call. Start at Grou and we'll show you where your current list is leaking meetings.
Two thousand accounts sit in your Clay table, half of them missing a headcount, and the sequence you're about to launch will bounce on every contact you can't verify.
Enrichment is a routing decision. A populated cell doesn't qualify a contact. Explicit rules do.
Field design drives the bill. Must-have fields and conditional fields have very different cost profiles.
Coverage numbers hide the trade-off. The provider with the most populated cells is often the least accurate one.
Governance sits at field level. A compliant provider doesn't make a compliant workflow.
Audit 200 records before you scale. Baseline the bounce rate first, then let the numbers decide.
The tool isn't the problem. The problem is that many treat enrichment as a fill-the-blanks exercise and skip the part where someone decides which records are safe to send to. Below is how I build that decision into a Clay workflow, where the credits go, and which records never leave the table.
Table of Contents
What Clay data enrichment adds to a lead record
A thin record forces a guess, and guesses get expensive at volume. Enrichment is the work of adding or refreshing attributes on a record: verified work email, phone number, headcount, industry, revenue band, installed technology, hiring activity, funding events, and job titles.
The Sacra profile of Clay traces how that work moved from single-source contact databases toward a marketplace connecting workflows with more than 150 data providers. The documented Intercom example shows the scale this reaches: in one month, Intercom sourced more than 4,000 accounts and enriched 21,000 contacts across firmographics, job postings, technology signals and contact attributes, which works out to roughly 5.25 enriched contacts per sourced account.
That ratio is the part worth copying. Account-level research and person-level enrichment belong in the same table, because the account decides whether you care and the person decides whether you can reach anyone.
Every field exists to route the record somewhere: into the sequence, into a review queue, or out of the table. A provider can fill every cell and still leave you guessing, since a low-confidence value behaves like an empty one unless you write the rule that handles it. Ask what each column decides before you ask how to fill it.
Firmographics answer fit. Technographics answer relevance. Hiring and funding answer timing. A record with only a name and an email answers none of those, so a rep opens it, guesses, and writes something generic.
What each enriched field actually decides
Field | Source type | Pipeline decision it supports |
|---|---|---|
Verified work email | Waterfall across email providers | Whether the contact is safe to send to |
Headcount and industry | Firmographic provider | Whether the account fits the ICP |
Installed technology | Technographic provider | Whether the account matches your integration needs |
Job postings and hiring activity | Hiring data source | When to start outreach |
Funding events | Funding data provider | Budget and timing signal |
Role and seniority | Person-level provider | Whether the buyer holds decision authority |
Personalization notes | AI research (Claygent) | Opening line, only when the claim has a cited source |
Name the three fields your next campaign depends on, then check whether the rows in your table carry them with a source attached. A row holding a value with no confidence signal behind it goes to review, not to the sequencer. Seven populated columns often reduce to the two that route the record.
How the waterfall calls providers in order
Take a single field: a work email for a US SaaS buyer list. Clay's waterfall documentation describes the mechanic precisely. Providers run sequentially for that one data point, and the chain stops once a valid result comes back, rather than sending the same lookup to every connected source.
That matters commercially. Every miss is a paid lookup, so the order you set determines which source wins the field and how many provider calls you buy before a match appears.
Here's the build I'd run for that list.
Name the field and its required input. An email lookup needs first name, last name and company domain. A phone lookup usually needs a LinkedIn profile URL. Partial inputs are the most common reason a provider returns nothing, and you still pay for the attempt.
Add the enrichment and set the order. Select Add enrichment, choose the waterfall, then reorder, add, delete or skip providers in the sequence panel. Start with whichever source covers your market best, not whichever vendor markets loudest.
Skip providers that can't serve the market. If a provider has thin coverage in a country or seniority band, remove it from that waterfall. Leaving it in spends lookups to learn what you already knew.
Write the validation rule. Accept only results marked valid, and let a miss or an invalid result fall through to the next provider. Without a stopping rule the chain keeps spending after it has a usable answer.
Output the winning provider and hide the middle columns. Keep a column that names the provider for each field. Hide the individual provider columns so the working table stays readable, but keep that name for the quality review later.
Add the run condition and turn on auto-update. Enrich only rows that already pass your ICP filter, so you never pay to enrich an account you wouldn't contact. Auto-update refreshes the field when a company or a person changes.
The end state is mundane and specific: enriched rows sync to HubSpot, then into Instantly or Smartlead for sequencing.
Working rule: a row without a provider name, a validation flag and a timestamp isn't enriched. It's guessed at.
A healthy table shows all three on every accepted row. When a field goes wrong six weeks later, that trio tells you whether the provider slipped, the refresh window lapsed, or the input was bad from the start.
What enrichment costs and how to budget credits
Clay meters two different things, and conflating them is why budgets surprise people. Actions measure work performed inside the workflow. Data Credits pay for information or AI supplied by third-party vendors in the marketplace, and Clay's university documentation puts Actions at a few tenths of a penny each and Data Credits at a few pennies, with the credit price varying by data type.
Each enrichment execution consumes one Action, and net-new third-party data generally consumes Data Credits unless you use free data or supply a private API key (Clay's FAQ on Actions and Data Credits). The practical split is simple: orchestration is cheap, answers are not.
Now the number that governs everything. A fully enriched person or company record typically costs 6 to 20 Data Credits when the workflow includes company and person profiles, email, phone and custom AI enrichments, per Clay's plans and billing documentation. That range is wide enough to break a budget on its own, and the same plan math gives these working tiers:
Plan | Monthly price from | Actions | Data credits | Fits teams enriching |
|---|---|---|---|---|
Starter plan | $185 | 15,000 | 2,500 to 10,000 | About 1,000 to 10,000 records per month |
Higher plan | $495 | 40,000 | 6,000 to 100,000 | 10,000 or more records per month |
Run the math on your own field list. At 6 credits per record, 2,500 credits cover about 416 fully enriched records. At 20 credits, the same 2,500 credits cover 125. At 10,000 credits you get roughly 1,666 records on the lean design or 500 on the heavy one.
That is why enrichment quality is a routing decision before it is a coverage number. A record that earns phone and AI research should already have passed fit, source validation and owner assignment; otherwise the expensive fields are being spent on rows sales will never touch.
Budget credits in this order
Forecast records per month, not campaigns per quarter. Record volume is what consumes credits.
Split fields into must-have and conditional. Verified work email and role are must-have. Phone, funding and AI research are conditional.
Run cheap firmographic and ICP filters first, so paid contact lookups only touch accounts that pass fit.
Gate the expensive fields behind routing rules. Phone and AI research run only on rows already assigned to a rep.
Set workbook or workflow credit limits before any large run. A cap set after the run is a bill, not a control.
Track cost per accepted contact. Cost per attempted row flatters a broad waterfall that mostly returns uncertainty.
Clay's pricing FAQ also publishes a lower entry point from $149 per month and a free trial of 1,000 credits for 14 days. Read that as a separate entry tier alongside the $185 and $495 plans in the table, then budget from whichever tier's Actions and Data Credits match your record math rather than the headline price.
One lever changes the shape of the bill. A private provider API key removes marketplace Data Credits on those lookups while the workflow still consumes Actions, so the marginal cost falls without disappearing. If you already pay for a provider you trust, that is the cheapest way to keep using it inside the table. For a side-by-side read on the tiers against monthly record volume, this breakdown of Clay pricing goes deeper than the plan page.
Measuring enrichment quality beyond coverage
More populated cells can lower pipeline quality, and the vendor comparisons show why. Clay's CRM enrichment guide reports that Hunter hit 97.15% accuracy on work emails but returned a verdict for only about half of records, while Findymail reached 90.26% coverage with lower accuracy.
Read that as a routing problem, not a sourcing problem. A waterfall that fills 90% of a column with addresses nobody verified has moved the failure downstream, where it shows up as bounces and a damaged sending domain instead of a blank cell.
The cost of that failure is not abstract. A 2026 compilation citing Gartner and MIT Sloan Management Review puts poor data quality at roughly $12.9 million per year for an affected organization, with revenue losses reaching 15% to 25% (data enrichment statistics). The same compilation reports that 47% of newly created records contain a critical error and that B2B databases decay by about 22.5% annually.
That decay figure is the one I plan around. Without a refresh process, nearly a quarter of a database's usable information goes stale over a year, which means enrichment is a recurring operation, not a one-time list build.
Five tests before a record reaches a rep
Test | What you measure | Fail state |
|---|---|---|
Coverage | Share of rows with a value for that field | An empty cell is not a pass |
Validity | Valid versus unknown or catch-all | Unknown or catch-all becomes do not contact |
Freshness | Days since collection against the refresh window | Older than the window goes back through the waterfall |
Confidence | Named provider and score versus the threshold | Below threshold goes to review, not outbound |
Business usefulness | Whether the field changes ICP, timing or buyer | A populated but unused field is dropped from the run |
Score each test by segment, geography, seniority and source. A waterfall that scores well on US mid-market SaaS can fail badly on manufacturing in DACH, and you'll only see it if you split the numbers.
Validity is the test teams skip most often, and it's the one that decides whether a send happens at all. If you're picking the verifier behind that flag, this comparison of email verification tools covers how each one handles catch-all and unknown results.
Unknown and catch-all emails never enter a sequence. Give them a do-not-contact state and leave them there until a verifier returns something definitive.
Records under your confidence threshold belong in a review queue, not in outbound. That's the same logic Grou uses on fit rules so sales doesn't spend time on wrong leads, and it's the reason a smaller accepted list beats a large uncertain one every time.
One caution on AI-generated fields. No independent benchmark of Claygent's accuracy or hallucination rate exists, so treat a scraped value proposition or an inferred intent score as a hypothesis. It needs a cited source before it becomes an opening line.
Here's the build in the interface, if you want to see the mechanics before wiring your own.
The other half of quality measurement is downstream. Track bounce rate, positive-reply rate, meeting rate and disqualification rate by provider and by segment. A provider that adds 8 points of coverage and 3 points of bounce has told you where it belongs.
Governing personal data across global outbound markets
A provider's compliance page protects the provider. Your workflow needs its own paper trail. Under the standard controller/processor split, the customer acts as controller, Clay acts as processor, and individual integrations can carry their own privacy terms. The legal exposure sits with you, not with the vendor whose badge is on the invoice.
Four operational questions land on the customer's desk. Which lawful basis applies in each target market. How to document the source and purpose of a personal contact field. How to honor a deletion or objection request when the record passed through five chained providers. Who answers when a provider's data turns out to be wrong.
The sharp version: a GDPR-compliant provider does not make a compliant workflow. Compliance lives in provenance, retention, refresh intervals, suppression lists, human review and downstream use. Any one of those can fail while every vendor on the invoice is certified. The test I'd apply is simple: could you produce the paper trail for one contact in under five minutes?
Build a control matrix before the next campaign
Set the matrix up per market, covering the EU and EEA, the UK, the US and any other region in your target list. Give each market four columns: lawful basis, retention period, refresh interval, and suppression list owner. One row per market, one owner per row, reviewed before a sequence goes live.
Then log every enriched field, not every record. The log needs five values:
Source URL, so you can show where a personal field came from.
Collection date, so freshness is auditable rather than assumed.
Confidence score, so a reviewer sees what the system thought of its own answer.
Lawful-purpose note, one line on why this field exists in this workflow.
Deletion status, updated when someone objects or asks to be removed.
A field with no logged source gets the same treatment as a field with a low confidence score. It routes to review, not to outbound, and it stays there until someone can defend it.
Human review goes on top for AI-scraped websites and personal social profiles. A model that reads a founder's LinkedIn post and drafts a line about it is producing a claim, not a fact, and the claim needs a reviewer before it reaches a sequence.
Grou documents its ICP, targeting criteria, sequences and fit rules so a client's team has full visibility and can take the system over or build on it. The data layer deserves the same standard.
A control matrix you can hand to counsel in ten minutes beats a compliance page you can't audit at all.
Treat this as an operating framework, not legal advice. Have counsel sign off on the matrix for each market before you scale sends into it. For the cold email side of the same problem, the GDPR cold email operator guide covers the sequence-level controls that sit on top of this data layer.
Clay versus single databases and manual research
Clay wins for teams enriching across several markets or field types. A single database wins for a stable ICP in one market when nobody on your team will maintain workflows. That's the verdict, and the rest of this section is the reasoning behind it.
Clay doesn't own a proprietary database. It sells orchestration across a marketplace of external providers, which is why provider selection and call order end up being go-to-market decisions rather than technical settings (Clay's FAQ on which actions cost credits). In manufacturing, pharma, legal tech or iGaming, coverage depends entirely on who you call and in what order.
Approach | How records get filled | Best when | Main risk |
|---|---|---|---|
Clay waterfall | Several providers called in order, stopping at the first valid result | Several markets or field types, with someone who maintains workflows | Quality and cost depend on provider order and rules |
Single database (ZoomInfo or Apollo) | One vendor's dataset per lookup | One market, stable ICP, no workflow owner | Gaps wherever that vendor is thin, with no fallback |
Clay with your own API keys | Your existing subscriptions run inside Clay | You already pay for providers you trust | Still needs per-provider governance and credit tracking |
Manual research with AI prompts | One account at a time | Under 100 accounts a month | Slow, hard to audit and does not scale |
The coverage claim floating around deserves the label it needs: it's vendor-reported. Clay states that an enterprise customer raised enrichment coverage from 30% with ZoomInfo to 80% with Clay while cutting cost from about $0.25 to less than $0.01 per enrichment (Clay's FAQ). Take it as a customer claim, not a benchmark you can assume for your own list.
Durability matters too when you're standardizing a workflow on one platform. Clay reports raising $115 million in Series D funding at a $7.1 billion valuation after fourfold revenue growth in 2025 (Clay's blog). A vendor that can fund its marketplace keeps adding providers. It doesn't guarantee any single provider is good in your market.
Where the answer flips
Two situations change my recommendation. If your ICP is one country, one seniority band and one industry, and no one on the team wants to own a waterfall, a single database returns more usable records per hour of effort. If you're enriching fewer than 100 accounts a month, a person with a research prompt and a verification step is cheaper than a platform.
Everything in between rewards orchestration. That's when you start comparing individual vendors on regional strength, which is a separate question from platform choice, and this comparison of Apollo versus Cognism is useful for the European coverage decision specifically.
For the provider-level view, this roundup of B2B data providers covers where each one is strong.
Run a 200-record enrichment audit this week
Stop tuning the waterfall by feel. Two hundred records will tell you more than a month of guessing, and the test costs less than a lunch.
Export 200 records across two segments. Pick one segment you convert well and one you lose. Same waterfall, same fields, two populations.
Run the waterfall you use today, and add a column naming the provider for each field. That column is the whole audit. Without it you're measuring the waterfall, not the sources inside it.
Have a person check 50 records against a source you trust. Open the company site, check the person's role, verify the email pattern. Fifty is enough to see a provider drifting.
Calculate coverage, validity and cost per accepted contact for each segment and each provider. Split the numbers, not the average. A blended figure hides the provider that's failing in one market.
Set the pass rule before you send anything. The waterfall passes only if accepted records beat your baseline on bounce rate without raising cost per accepted contact. Decide that now, while you're still unbiased.
Send accepted and flagged records into separate sequences. Compare bounce rate and reply rate after two weeks. Flagged records that perform inside a tolerance band are your evidence for loosening a rule. Flagged records that bounce confirm it.
If the audit shows your gap sits at account level rather than contact level, this account research workflow walks through the research steps that feed the same table before you spend a credit on contact data.
The order matters. Many teams run the send first and the audit after, which means the audit is really a post-mortem on a damaged domain.
If you're not sure whether the bottleneck is your data, your targeting or your messaging, the two-minute pipeline quiz shows where your pipeline breaks and which service fits best.
Grou has built B2B pipeline systems for more than 50 companies across iGaming, SaaS, manufacturing, legal tech and pharma. Every workflow is documented, so your team can audit it, change it, or take it over entirely.
If your table is full of rows nobody has verified, that's a pipeline problem before it's a data problem. Grou builds the enrichment layer, the fit rules and the outbound sequences as one system, so the records that reach a rep are already worth the call. Start at Grou and we'll show you where your current list is leaking meetings.
Pipeline OS Newsletter
Build qualified pipeline
Get weekly tactics to generate demand, improve lead quality, and book more meetings.
Trusted by industry leaders
Trusted by industry leaders
Trusted by industry leaders
Ready to build qualified pipeline?
Ready to build qualified pipeline?
Ready to build qualified pipeline?
Book a call to see if we're the right fit, or take the 2-minute quiz to get a clear starting point.
Book a call to see if we're the right fit, or take the 2-minute quiz to get a clear starting point.
Book a call to see if we're the right fit, or take the 2-minute quiz to get a clear starting point.
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 30 30" xmlns="http://www.w3.org/2000/svg"><path d="M 15.108 0 C 6.764 0 0 6.764 0 15.108 C 0 23.452 6.764 30.216 15.108 30.216 C 23.452 30.216 30.216 23.452 30.216 15.108 C 30.216 6.764 23.452 0 15.108 0 Z M 11.41 21.37 L 8.35 21.37 L 8.35 11.525 L 11.41 11.525 Z M 9.861 10.316 C 8.895 10.316 8.27 9.631 8.27 8.785 C 8.27 7.921 8.914 7.257 9.901 7.257 C 10.887 7.257 11.492 7.921 11.511 8.785 C 11.511 9.631 10.887 10.316 9.861 10.316 Z M 22.584 21.37 L 19.524 21.37 L 19.524 15.914 C 19.524 14.644 19.08 13.782 17.974 13.782 C 17.129 13.782 16.627 14.365 16.405 14.927 C 16.323 15.127 16.303 15.41 16.303 15.692 L 16.303 21.369 L 13.242 21.369 L 13.242 14.664 C 13.242 13.435 13.202 12.408 13.161 11.523 L 15.82 11.523 L 15.96 12.891 L 16.021 12.891 C 16.424 12.249 17.411 11.301 19.062 11.301 C 21.074 11.301 22.584 12.65 22.584 15.549 Z" fill="rgb(0, 0, 0)" height="30.21639343089746px" id="hfGbXmQR2" width="30.216393430897455px"/></svg>)
Copyright © 2026 – All Right Reserved
Copyright © 2026 – All Right Reserved
Copyright © 2026 – All Right Reserved