What Entity Resolution Is and Why It Matters
Entity resolution is the process of determining when records from different systems refer to the same real-world thing. It matters because enterprises cannot trust analytics, automation, or AI outputs when customer, product, supplier, or asset data is fragmented across duplicate and conflicting records. In practice, entity resolution is what turns scattered records into a usable, governed view of the business.
At a basic level, entity resolution—also called record linkage—matches and merges records that describe the same entity even when the data is incomplete, inconsistent, or formatted differently. A single customer might appear as "Acme Inc.," "ACME Incorporated," and "Acme, LLC" across CRM, ERP, billing, and support systems. The goal is not just deduplication. It is identifying relationships, resolving ambiguity, and creating a more complete profile that downstream systems can trust. IBM describes entity resolution as the process of analyzing records and identifying which ones represent the same entity, despite variations in the source data, while modern platforms increasingly combine rules, machine learning, and graph techniques to improve accuracy at scale (IBM, Stardog, Tamr).
This is where enterprises struggle. Duplicate records are rarely simple copies. They are usually created by disconnected systems, acquisitions, regional business units, manual entry, changing identifiers, and inconsistent data standards. One system may store a legal entity name, another a brand name, and a third a billing contact. Addresses change. Emails are shared. Product attributes are modeled differently by team or geography. As a result, exact-match logic breaks quickly, but fully manual cleanup does not scale.
The Entity Resolution Workflow
Ingest source records from CRM, ERP, product, and third-party systems into a common pipeline. Preserve source IDs and lineage for traceability. See IBM on entity resolution.
Standardize fields before comparison. Normalize names, addresses, phone numbers, formats, and null handling so records are comparable. Wikipedia's record linkage overview is a solid baseline.
Match records using deterministic rules and probabilistic or ML scoring. Exact keys handle obvious duplicates; fuzzy logic handles messy real-world data. Stardog's entity resolution docs and Tamr's overview cover this well.
Cluster matched pairs into entities so all related records roll up to one identity.
Apply survivorship rules to choose the best values per attribute based on trust, recency, and completeness. Informatica's MDM overview is useful here.
Publish the golden record to downstream systems and analytics layers.
Monitor drift by tracking match quality, source changes, and data quality regressions over time.
The business impact is bigger than data hygiene. Poor entity resolution leads to broken customer 360 initiatives, inflated pipeline counts, fragmented service histories, compliance risk, and unreliable reporting. It also weakens AI use cases, because models grounded in messy enterprise data inherit that confusion. Informatica frames the adjacent challenge as identity resolution: connecting fragmented signals into a trusted profile that can support better decisions and experiences (Informatica). For enterprises, that is the real value: fewer duplicates, better context, and one version of the truth that operational and analytical systems can actually use.
How Entity Resolution Works in Practice
In practice, entity resolution is the layer that turns messy, duplicated records into a usable representation of a customer, supplier, product, or organization. It starts with record linkage: comparing records from CRMs, warehouses, support tools, event streams, and third-party sources to determine whether they refer to the same real-world entity. That usually begins with standardization and parsing. Names, addresses, emails, phone numbers, company identifiers, and product attributes are normalized so the system can compare like with like. From there, matching logic evaluates similarity across fields using deterministic rules, probabilistic methods, or machine learning. Deterministic matching works well when there is a stable key, like a tax ID or customer ID. Probabilistic matching is better when data is incomplete or inconsistent, because it weighs multiple weak signals together rather than relying on a single exact match. IBM's overview of record linkage is a useful primer, and Galaxy's guide to entity resolution frames the enterprise use case well.
Once candidate matches are identified, the system has to decide what to keep. This is where survivorship and confidence scoring matter. Confidence scoring assigns a probability or match score to each linked pair or cluster, helping teams separate high-certainty merges from records that need review. Survivorship then determines the "best" value for each attribute in the golden record. One source may be most trusted for legal name, another for billing address, and another for recent behavioral data. Modern platforms often combine source trust, recency, completeness, and validation status to choose the surviving value. Informatica's explanation of identity resolution is helpful here because it connects matching logic to stewardship and downstream activation.
The next practical decision is when matching happens. Batch matching is still common for warehouse-scale consolidation, periodic MDM jobs, and historical cleanup. It is efficient for large volumes and easier to govern. Real-time matching matters when identity needs to be resolved during an operational workflow, such as onboarding a customer, screening a vendor, or enriching an account before a sales action. In those cases, the system evaluates incoming records against an existing entity graph or index with low latency, then returns a match decision and confidence score immediately. Tamr's discussion of real-time entity resolution is a good reference for this shift.
In modern data architecture, entity resolution sits between raw ingestion and downstream consumption. It is not just an MDM feature anymore. It increasingly operates as a shared service across the lakehouse, warehouse, reverse ETL, governance, and AI layers. Resolved entities feed analytics, personalization, fraud detection, and retrieval systems with cleaner context. In graph-oriented architectures, entity resolution also becomes the mechanism that connects records into a persistent network of relationships, which Stardog outlines in its documentation on entity resolution. The practical takeaway is simple: entity resolution is the operational process that makes fragmented enterprise data trustworthy enough to use.
What Business Outcomes Entity Resolution Enables
Entity resolution creates business value when it turns fragmented records into trusted, usable entities. The first outcome is a single customer view: matching and linking records across CRM, support, billing, product usage, and partner systems so teams can understand that "Acme Inc.," "Acme Corporation," and a subsidiary account are part of the same real-world customer. That unified view improves segmentation, account planning, service handoffs, and revenue reporting because decisions are based on the customer as it actually exists, not as it appears in one source system. IBM frames this as connecting records that refer to the same entity across disparate data sources, which is the foundation for better operational and analytical decisions (IBM entity resolution overview).
The second outcome is the creation of golden records. Once duplicate and conflicting records are identified, organizations can apply survivorship rules, confidence scoring, and stewardship workflows to produce a best-version record for each customer, supplier, product, or location. In master data management, that golden record becomes the trusted reference point used across downstream systems and processes. This reduces duplicate outreach, inconsistent reporting, and manual reconciliation. It also gives data teams a practical way to standardize identity without forcing every source system to look the same. For background on how golden records fit into MDM, see Golden record (informatics) and IBM's overview of master data management.
Entity resolution also has a direct impact on product master data quality. Product data is often scattered across ERP, PIM, supplier feeds, ecommerce catalogs, and regional systems, with inconsistent SKUs, naming conventions, units, and hierarchies. Resolving those records into a coherent product entity improves catalog accuracy, procurement efficiency, search and merchandising, and supply chain reporting. It helps teams identify when multiple records describe the same item, when attributes conflict, and where enrichment is missing. That is a core reason MDM programs invest in mastering product data: better consistency leads to fewer operational errors and more reliable analytics. Informatica's explanation of master data management and Snowflake's overview of MDM both reinforce this link between mastered data and business process quality.
Finally, entity resolution supports governance, compliance, and AI. Governance programs depend on knowing what an entity is, where its data lives, and which record should be treated as authoritative. That matters for privacy rights, consent management, auditability, and policy enforcement. NIST defines data governance as the management of data's availability, usability, integrity, and security (NIST data governance glossary), and entity resolution strengthens each of those dimensions by reducing ambiguity. The same foundation is increasingly important for AI and retrieval workflows: models perform better when customer, product, and organizational entities are deduplicated, linked, and grounded in trusted context. In practice, better entity resolution means cleaner retrieval, fewer hallucinations caused by conflicting records, and more reliable enterprise AI outputs.
Enterprise Use Cases and Examples
Entity resolution becomes valuable when it moves from theory into operational workflows. In enterprise settings, the goal is usually simple: connect records that refer to the same real-world customer, product, supplier, or patient, even when those records are incomplete, duplicated, or formatted differently. Platforms such as AWS Entity Resolution and IBM's overview of entity resolution frame this as the foundation for a trusted, shared view of core business entities.
A common use case is customer data unification across CRM, support, and billing systems. A B2B company may have one account in Salesforce, several contacts in Zendesk, and multiple billing profiles in NetSuite or Stripe. Entity resolution links those records using identifiers such as company name, domain, email, billing address, and account owner, then creates a persistent golden record. That unified profile supports a true single customer view: sales can see open support issues before renewal calls, finance can spot duplicate invoices, and customer success can measure product adoption at the account level instead of by disconnected records.
The same pattern applies to product data consolidation. Large manufacturers and retailers often manage overlapping product records from ERP systems, supplier catalogs, distributor feeds, and ecommerce platforms. One SKU may appear under different names, package sizes, or supplier-specific codes. Entity resolution clusters those variants into a canonical product entity, then maps attributes such as brand, dimensions, compliance fields, and lifecycle status. This is especially important in regulated environments where identifiers matter. In healthcare and life sciences, for example, the FDA's Unique Device Identification (UDI) framework shows why consistent product identity is critical for traceability, recalls, and reporting.
Supplier and vendor deduplication is another high-value workflow. Procurement teams often inherit fragmented vendor masters after acquisitions or regional system rollouts. "Acme Ltd.," "Acme Limited," and "ACME Holdings UK" may all represent the same supplier, but sit in separate AP and sourcing systems. Entity resolution helps normalize names, addresses, tax IDs, banking details, and parent-child relationships so teams can reduce duplicate payments, improve spend analysis, and enforce supplier risk controls. Vendors like Tamr and Stardog highlight this workflow because it directly improves sourcing leverage and compliance.
Industry examples make the value even clearer. In healthcare, patient identity matching supports cleaner master patient indexes and safer care coordination; ONC's patient matching work underscores the operational need for accurate cross-system identity resolution in clinical data exchange (HealthIT.gov). In financial services, banks use entity resolution in KYC and AML workflows to connect customers, beneficial owners, accounts, and counterparties across onboarding, sanctions screening, and transaction monitoring. In retail, teams use it to unify customer profiles across loyalty, ecommerce, POS, and service channels while also consolidating product and supplier records for cleaner merchandising and inventory decisions. In each case, the workflow is the same: ingest fragmented records, match and cluster likely duplicates, assign a trusted entity, and push that resolved view back into downstream systems.
Entity Resolution Methods and Technical Considerations
Entity resolution combines records that refer to the same real-world entity across systems, even when identifiers are missing or inconsistent. In practice, the first design choice is between deterministic and probabilistic matching. Deterministic matching uses exact or near-exact rules on stable attributes such as tax IDs, email addresses, or normalized legal names. It is fast, transparent, and easy to audit, but it breaks down when data is incomplete, stale, or formatted differently. Probabilistic matching, often described in the record linkage literature, assigns weights to multiple signals and estimates whether two records represent the same entity despite variation or noise. This approach is more resilient in messy environments, but it requires threshold tuning and stronger governance around false positives and false negatives. A useful technical baseline is the classic record linkage overview, with formal statistical grounding from NIST's work on entity resolution and evaluation.
The second choice is rules-based versus machine learning approaches. Rules-based systems encode domain knowledge directly: normalize names, standardize addresses, compare aliases, and require specific field combinations before merging. That works well when data patterns are known and compliance teams need explicit logic. ML-based approaches learn match patterns from labeled examples or use similarity models to score candidate pairs at scale. They are better at handling ambiguous, semi-structured, and multilingual data, but they introduce model drift, training data bias, and explainability challenges. In most production environments, the strongest pattern is hybrid: deterministic rules for high-confidence joins, probabilistic or ML scoring for ambiguous cases, and a review queue for edge cases. Major platforms reflect this blended model, including AWS Entity Resolution and graph-oriented approaches such as Stardog Entity Resolution.
Technical implementation also depends on the shape of the data. Structured sources like CRM, ERP, and MDM tables support field-level comparison and survivorship logic. Semi-structured sources such as JSON documents, support tickets, contracts, and web data require parsing, schema mapping, and feature extraction before matching. Across both, accuracy depends on normalization, blocking to reduce comparison volume, threshold calibration, and continuous measurement. Just as important, resolution decisions must be explainable: teams need to see why records matched, which attributes contributed, and where confidence is low. Human review remains essential for high-impact merges, regulated workflows, and ongoing quality control.
How to Evaluate Entity Resolution Vendors
Enterprise entity resolution is no longer just a matching engine. The best platforms combine high-accuracy resolution with operational fit: they must work at enterprise scale, support low-latency decisions, preserve governance, and plug cleanly into the existing data stack. In practice, evaluation should start with the deployment model and decision loop. Some teams need batch unification for customer, supplier, or product master data. Others need near-real-time resolution for onboarding, fraud, service, or AI applications. A vendor that scores well in offline matching but struggles with latency, explainability, or integration often becomes a bottleneck later.
What to look for in enterprise platforms: flexible matching methods, support for multiple entity types, transparent confidence scoring, survivorship and golden-record controls, and strong workflow around review and stewardship. Enterprise buyers should also test whether the platform can resolve entities across fragmented schemas without forcing a full rip-and-replace MDM program. Modern platforms increasingly differentiate on interoperability: APIs, event support, warehouse/lakehouse compatibility, graph-friendly modeling, and the ability to activate resolved entities downstream in analytics and operational systems. Relevant vendor references include Galaxy, Reltio, Informatica, Tamr, Senzing, and AWS Entity Resolution.
Key evaluation criteria should stay compact and measurable:
Scale: Can the platform handle billions of records, frequent updates, and multi-domain resolution without major re-architecture?
Latency: Does it support batch and low-latency or real-time use cases, not just periodic matching?
Governance: Are match rules, lineage, stewardship, auditability, and policy controls built in?
Interoperability: Does it integrate with cloud storage, warehouses, MDM, CRM, identity, and AI pipelines through APIs and connectors?
Explainability: Can teams understand why records matched, merged, or stayed separate?
Operational overhead: How much tuning, data engineering, and specialist support is required to keep quality high?
Vendor Comparison
Vendor | Best Fit | Scale | Latency | Governance | Interoperability |
|---|---|---|---|---|---|
Semantic data unification and enterprise knowledge layers | High | Low-latency capable | Strong | Strong | |
Cloud-native MDM and customer/entity resolution | High | Strong | Strong | Strong | |
Large enterprises with broad data governance needs | High | Moderate to strong | Very strong | Very strong | |
Large-scale data mastering and complex source consolidation | High | Moderate | Strong | Strong | |
Fast, explainable resolution for risk, fraud, and ops | High | Strong | Moderate | Moderate to strong | |
Cloud-native matching inside AWS ecosystems | Moderate to high | Moderate | Moderate | Strong in AWS |
A common gap in legacy MDM is that it was built for centralized master records, not continuous, cross-system resolution. Older stacks often rely on rigid schemas, batch-heavy processing, brittle match rules, and expensive stewardship queues. They may govern mastered data well, but struggle with low-latency activation, multi-hop relationships, and interoperability across modern warehouses, lakehouses, SaaS apps, and AI systems. That is why vendor evaluation should focus less on "can it match records?" and more on "can it resolve entities continuously, govern them safely, and make them usable everywhere?"
Choosing the Right Approach for Enterprise Semantic Data Unification
Choosing the right approach depends on the scope of the data problem. Standalone entity resolution is often enough when the goal is narrow and operational: deduplicating customer, supplier, or product records across a few systems; improving match accuracy for a specific workflow; or cleaning data before migration. In those cases, the priority is high-confidence matching, survivorship rules, and measurable improvements in record quality. Platforms focused on ER can work well here, especially when the business does not yet need a shared semantic model across domains. For background on AI-native ER in MDM, Tamr's overview is a useful reference: Tamr entity resolution.
The limits show up when matching is no longer the whole problem. Large enterprises rarely struggle only with duplicate records. They struggle with inconsistent meaning across systems: different definitions of customer, product, policy, asset, or location; fragmented metadata; and weak context for analytics and AI. That is where ER should sit inside a broader semantic layer. A semantic unification approach connects resolved entities to business concepts, relationships, and governance rules, so the organization is not just deciding that two records are the same, but also defining how that entity relates to the rest of the business. Galaxy's perspective on this architecture is outlined in its semantic data unification blueprint.
This is also the bridge to master data, knowledge graphs, and AI readiness. Master data management provides control, stewardship, and golden-record discipline; ER improves identity accuracy inside that process; and knowledge graphs add relationship-rich context that traditional tables often miss. Informatica's primer on master data management is helpful here, while Neo4j's explanation of knowledge graphs shows why connected context matters. For enterprises preparing data for copilots, agents, and retrieval workflows, semantic unification becomes the stronger long-term choice because AI systems need more than clean records. They need governed meaning, linked context, and a structure that machines can reason over.
Entity Resolution vs MDM vs CDP vs Identity Resolution
Approach | Primary Focus | Scope | Best For | Limitations |
|---|---|---|---|---|
Matches and merges records that refer to the same real-world entity, even when data is messy, incomplete, or inconsistent. | Broad and domain-agnostic: customers, suppliers, products, locations, organizations. Often used inside data integration, analytics, and knowledge graph workflows. | Multi-source data unification where the core problem is "are these the same thing?" Especially strong for B2B, operational data, and non-customer entities. | Does not by itself provide governance, stewardship, or a full golden-record operating model like MDM. | |
Creates a trusted, governed system of record for core business entities. Focuses on standardization, survivorship, stewardship, hierarchy management, and ongoing data quality. | Enterprise-wide management of master data: customer, product, supplier, and location domains. Spans processes, policies, workflows, and integration patterns. | Organizations that need governed golden records across business units and systems. Best when compliance, ownership, auditability, and operational consistency matter. | Heavier to implement and maintain. Can be slower to deliver value if the immediate need is only matching or deduplication; Informatica's overview. | |
Unifies customer data to support segmentation, personalization, activation, and measurement. Emphasis is marketing and customer experience use cases. | Customer-centric: marketing, sales, service, and digital engagement data. Ingests behavioral, transactional, and profile data for downstream activation; Segment's CDP overview. | Marketing teams that need a usable customer profile for audiences, journeys, and campaign orchestration. Best when activation speed matters more than enterprise-wide data governance. | Usually narrower than MDM and not designed to govern every enterprise entity. Product, supplier, or complex operational domains are typically out of scope. | |
Connects identifiers and interactions belonging to the same person or household across devices, channels, and touchpoints. A specialized form of matching focused on persistent customer identity. | Mostly customer and audience identity across anonymous and known states. Common in adtech, martech, and customer data stacks. | Omnichannel personalization, attribution, suppression, and frequency control. Best when the challenge is recognizing the same customer across fragmented identifiers. | Narrower than general entity resolution because it centers on people/households and marketing identity graphs. Privacy constraints and signal loss can reduce accuracy. |
The bottom line: Entity resolution = matching problem. MDM = governed master record operating model. CDP = customer data unification for activation. Identity resolution = customer identity stitching across identifiers.
Frequently Asked Questions About Entity Resolution
What is entity resolution, and how is it different from record linkage?
Entity resolution is the broader process of identifying, matching, and consolidating records that refer to the same real-world entity across systems. Record linkage is a closely related technique, often used more narrowly for matching records across datasets. In practice, record linkage is usually one step inside a larger ER workflow. Sources: Galaxy, IBM
How does entity resolution help create a single customer view?
Entity resolution connects customer records from CRM, billing, support, product usage, and marketing systems into one trusted profile. That makes it possible to see the same person or account across touchpoints, reduce fragmentation, and support better service, analytics, and personalization. A single customer view depends on accurate matching first. Sources: Galaxy, Experian
What is a golden record in entity resolution?
A golden record is the most trusted, complete representation of an entity after duplicate and conflicting records have been reconciled. Entity resolution helps determine which records belong together; survivorship and governance rules then decide which attributes become authoritative. The result is a cleaner master profile for downstream systems and analytics. Sources: Galaxy, Galaxy
Can entity resolution support product master data, not just customer data?
Yes. Entity resolution is useful for product, supplier, asset, and location data as well as customer data. In product master data, it helps unify duplicate SKUs, inconsistent descriptions, supplier-specific identifiers, and overlapping catalog entries across ERP, PLM, PIM, and ecommerce systems. That improves search, reporting, and operational consistency. Sources: Galaxy, Galaxy
What does real-time entity resolution mean?
Real-time entity resolution means matching and updating entity profiles as new records or events arrive, rather than waiting for nightly or weekly batch jobs. This matters in fraud detection, customer support, personalization, and operational workflows where context changes quickly. The challenge is balancing speed, match accuracy, and governance at production scale. Sources: Galaxy, Experian
How is entity resolution different from MDM, identity resolution, and deduplication?
Entity resolution focuses on deciding which records refer to the same entity. MDM is broader: it adds governance, stewardship, workflows, hierarchies, and distribution of trusted master data. Identity resolution usually focuses on people and cross-channel identifiers, often in marketing contexts. Deduplication is narrower still, typically removing obvious duplicates within one system. Sources: Galaxy, Experian
Why isn't simple deduplication enough?
Simple deduplication catches exact or near-exact duplicates, but most enterprise data problems are messier. Names change, addresses vary, product codes differ by source, and records may be incomplete or contradictory. Entity resolution uses rules, probabilistic matching, graph relationships, or machine learning to connect records that are related even when they do not look identical. Sources: Galaxy, IBM
What is the cost of poor data quality when entity resolution is missing?
Poor data quality drives duplicate outreach, broken reporting, wasted operations, compliance risk, and bad AI outputs. When the same customer, supplier, or product appears in multiple inconsistent forms, teams lose trust in dashboards and workflows. Entity resolution reduces that fragmentation by creating a more reliable foundation for decisions and automation. Sources: HBR, Galaxy
How does entity resolution support AI and generative AI use cases?
AI systems perform better when the underlying entities are clean, connected, and contextualized. Entity resolution helps unify fragmented records into consistent profiles, which improves retrieval, feature quality, grounding, and explainability. For generative AI, that means fewer contradictory answers and better enterprise context when models reason over customers, products, suppliers, or assets. Sources: Galaxy, Galaxy
How do teams know whether entity resolution is working?
Strong ER programs track both technical and business outcomes. Common measures include precision, recall, false match rate, duplicate reduction, profile completeness, and downstream impact on service, analytics, or conversion. The goal is not just more matches, but more trustworthy entity profiles that improve operational and analytical decisions. Sources: Galaxy
Interested in learning more about Galaxy?
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><g d="M 0 24 L 0 0 L 24 0 L 24 24 Z M 21.829 0 L 2.171 0 C 0.972 0 0 0.972 0 2.171 L 0 21.829 C 0 23.028 0.972 24 2.171 24 L 21.829 24 C 23.028 24 24 23.028 24 21.829 L 24 2.171 C 24 0.972 23.028 0 21.829 0 Z M 7.427 20.723 C 7.427 21.072 7.144 21.355 6.795 21.355 L 4.105 21.355 C 3.756 21.355 3.474 21.072 3.474 20.723 L 3.474 9.449 C 3.474 9.1 3.756 8.818 4.105 8.818 L 6.795 8.818 C 7.144 8.818 7.427 9.1 7.427 9.449 Z M 5.45 7.755 C 4.039 7.755 2.895 6.611 2.895 5.2 C 2.895 3.789 4.039 2.645 5.45 2.645 C 6.861 2.645 8.005 3.789 8.005 5.2 C 8.005 6.611 6.861 7.755 5.45 7.755 Z M 21.481 20.774 C 21.481 21.095 21.221 21.355 20.9 21.355 L 18.014 21.355 C 17.694 21.355 17.433 21.095 17.433 20.774 L 17.433 15.486 C 17.433 14.697 17.665 12.029 15.372 12.029 C 13.593 12.029 13.233 13.855 13.16 14.675 L 13.16 20.774 C 13.16 21.095 12.9 21.355 12.579 21.355 L 9.788 21.355 C 9.467 21.355 9.207 21.095 9.207 20.774 L 9.207 9.399 C 9.207 9.078 9.467 8.818 9.788 8.818 L 12.579 8.818 C 12.9 8.818 13.16 9.078 13.16 9.399 L 13.16 10.382 C 13.82 9.392 14.8 8.628 16.887 8.628 C 21.508 8.628 21.481 12.946 21.481 15.318 Z" fill="transparent" height="24px" id="czQM6Cy8P" width="24px"><path d="M 0 24 L 0 0 L 24 0 L 24 24 Z" fill="transparent" height="24px" id="U6Mx_RyPt" width="24px"/><path d="M 21.829 0 L 2.171 0 C 0.972 0 0 0.972 0 2.171 L 0 21.829 C 0 23.028 0.972 24 2.171 24 L 21.829 24 C 23.028 24 24 23.028 24 21.829 L 24 2.171 C 24 0.972 23.028 0 21.829 0 Z M 7.427 20.723 C 7.427 21.072 7.144 21.355 6.795 21.355 L 4.105 21.355 C 3.756 21.355 3.474 21.072 3.474 20.723 L 3.474 9.449 C 3.474 9.1 3.756 8.818 4.105 8.818 L 6.795 8.818 C 7.144 8.818 7.427 9.1 7.427 9.449 Z M 5.45 7.755 C 4.039 7.755 2.895 6.611 2.895 5.2 C 2.895 3.789 4.039 2.645 5.45 2.645 C 6.861 2.645 8.005 3.789 8.005 5.2 C 8.005 6.611 6.861 7.755 5.45 7.755 Z M 21.481 20.774 C 21.481 21.095 21.221 21.355 20.9 21.355 L 18.014 21.355 C 17.694 21.355 17.433 21.095 17.433 20.774 L 17.433 15.486 C 17.433 14.697 17.665 12.029 15.372 12.029 C 13.593 12.029 13.233 13.855 13.16 14.675 L 13.16 20.774 C 13.16 21.095 12.9 21.355 12.579 21.355 L 9.788 21.355 C 9.467 21.355 9.207 21.095 9.207 20.774 L 9.207 9.399 C 9.207 9.078 9.467 8.818 9.788 8.818 L 12.579 8.818 C 12.9 8.818 13.16 9.078 13.16 9.399 L 13.16 10.382 C 13.82 9.392 14.8 8.628 16.887 8.628 C 21.508 8.628 21.481 12.946 21.481 15.318 Z" fill="rgb(255, 255, 255)" height="24px" id="PKt6RW0lu" width="24px"/></g></svg>)
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><g d="M 0 23.51 L 0 0 L 24 0 L 24 23.51 Z M 10.148 16.992 C 7.055 16.617 4.875 14.391 4.875 11.508 C 4.875 10.336 5.297 9.07 6 8.227 C 5.695 7.453 5.742 5.813 6.094 5.133 C 7.031 5.016 8.297 5.508 9.047 6.187 C 9.937 5.906 10.875 5.766 12.023 5.766 C 13.172 5.766 14.109 5.906 14.953 6.164 C 15.68 5.508 16.969 5.016 17.906 5.133 C 18.234 5.766 18.281 7.406 17.977 8.203 C 18.727 9.094 19.125 10.289 19.125 11.508 C 19.125 14.391 16.945 16.57 13.805 16.969 C 14.602 17.484 15.141 18.609 15.141 19.898 L 15.141 22.336 C 15.141 23.039 15.727 23.438 16.43 23.156 C 20.672 21.539 24 17.297 24 12.047 C 24 5.414 18.609 0 11.977 0 C 5.344 0 0 5.414 0 12.047 C 0 17.25 3.305 21.563 7.758 23.18 C 8.391 23.414 9 22.992 9 22.359 L 9 20.484 C 8.672 20.625 8.25 20.719 7.875 20.719 C 6.328 20.719 5.414 19.875 4.758 18.305 C 4.5 17.672 4.219 17.297 3.68 17.227 C 3.398 17.203 3.305 17.086 3.305 16.945 C 3.305 16.664 3.773 16.453 4.242 16.453 C 4.922 16.453 5.508 16.875 6.117 17.742 C 6.586 18.422 7.078 18.727 7.664 18.727 C 8.25 18.727 8.625 18.516 9.164 17.977 C 9.563 17.578 9.867 17.227 10.148 16.992 Z" fill="transparent" height="23.5102px" id="pBWMFa8Zs" width="24px"><path d="M 0 23.51 L 0 0 L 24 0 L 24 23.51 Z" fill="transparent" height="23.5102px" id="mpuVqkNhx" width="24px"/><g d="M 10.148 16.992 C 7.055 16.617 4.875 14.391 4.875 11.508 C 4.875 10.336 5.297 9.07 6 8.227 C 5.695 7.453 5.742 5.813 6.094 5.133 C 7.031 5.016 8.297 5.508 9.047 6.187 C 9.937 5.906 10.875 5.766 12.023 5.766 C 13.172 5.766 14.109 5.906 14.953 6.164 C 15.68 5.508 16.969 5.016 17.906 5.133 C 18.234 5.766 18.281 7.406 17.977 8.203 C 18.727 9.094 19.125 10.289 19.125 11.508 C 19.125 14.391 16.945 16.57 13.805 16.969 C 14.602 17.484 15.141 18.609 15.141 19.898 L 15.141 22.336 C 15.141 23.039 15.727 23.438 16.43 23.156 C 20.672 21.539 24 17.297 24 12.047 C 24 5.414 18.609 0 11.977 0 C 5.344 0 0 5.414 0 12.047 C 0 17.25 3.305 21.563 7.758 23.18 C 8.391 23.414 9 22.992 9 22.359 L 9 20.484 C 8.672 20.625 8.25 20.719 7.875 20.719 C 6.328 20.719 5.414 19.875 4.758 18.305 C 4.5 17.672 4.219 17.297 3.68 17.227 C 3.398 17.203 3.305 17.086 3.305 16.945 C 3.305 16.664 3.773 16.453 4.242 16.453 C 4.922 16.453 5.508 16.875 6.117 17.742 C 6.586 18.422 7.078 18.727 7.664 18.727 C 8.25 18.727 8.625 18.516 9.164 17.977 C 9.563 17.578 9.867 17.227 10.148 16.992 Z" fill="transparent" height="23.247157673850985px" id="UJ2btNb6V" width="24px"><path d="M 10.148 16.992 C 7.055 16.617 4.875 14.391 4.875 11.508 C 4.875 10.336 5.297 9.07 6 8.227 C 5.695 7.453 5.742 5.813 6.094 5.133 C 7.031 5.016 8.297 5.508 9.047 6.187 C 9.937 5.906 10.875 5.766 12.023 5.766 C 13.172 5.766 14.109 5.906 14.953 6.164 C 15.68 5.508 16.969 5.016 17.906 5.133 C 18.234 5.766 18.281 7.406 17.977 8.203 C 18.727 9.094 19.125 10.289 19.125 11.508 C 19.125 14.391 16.945 16.57 13.805 16.969 C 14.602 17.484 15.141 18.609 15.141 19.898 L 15.141 22.336 C 15.141 23.039 15.727 23.438 16.43 23.156 C 20.672 21.539 24 17.297 24 12.047 C 24 5.414 18.609 0 11.977 0 C 5.344 0 0 5.414 0 12.047 C 0 17.25 3.305 21.563 7.758 23.18 C 8.391 23.414 9 22.992 9 22.359 L 9 20.484 C 8.672 20.625 8.25 20.719 7.875 20.719 C 6.328 20.719 5.414 19.875 4.758 18.305 C 4.5 17.672 4.219 17.297 3.68 17.227 C 3.398 17.203 3.305 17.086 3.305 16.945 C 3.305 16.664 3.773 16.453 4.242 16.453 C 4.922 16.453 5.508 16.875 6.117 17.742 C 6.586 18.422 7.078 18.727 7.664 18.727 C 8.25 18.727 8.625 18.516 9.164 17.977 C 9.563 17.578 9.867 17.227 10.148 16.992 Z" fill="rgb(255, 255, 255)" height="23.247157673850985px" id="M3DBdZhx2" width="24px"/></g></g></svg>)
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 24 25" xmlns="http://www.w3.org/2000/svg"><g d="M 0 24.54 L 0 0 L 24 0 L 24 24.54 Z M 14.283 10.386 L 23.218 0 L 21.101 0 L 13.343 9.018 L 7.147 0 L 0 0 L 9.37 13.636 L 0 24.527 L 2.117 24.527 L 10.31 15.004 L 16.853 24.527 L 24 24.527 L 14.283 10.386 Z M 11.383 13.757 L 10.434 12.399 L 2.88 1.594 L 6.132 1.594 L 12.228 10.314 L 13.178 11.672 L 21.102 23.006 L 17.849 23.006 L 11.383 13.757 Z" fill="transparent" height="24.54px" id="qrHd8I4vg" width="24px"><path d="M 0 24.54 L 0 0 L 24 0 L 24 24.54 Z" fill="transparent" height="24.54px" id="YCI2O2hpY" width="24px"/><path d="M 14.283 10.386 L 23.218 0 L 21.101 0 L 13.343 9.018 L 7.147 0 L 0 0 L 9.37 13.636 L 0 24.527 L 2.117 24.527 L 10.31 15.004 L 16.853 24.527 L 24 24.527 L 14.283 10.386 Z M 11.383 13.757 L 10.434 12.399 L 2.88 1.594 L 6.132 1.594 L 12.228 10.314 L 13.178 11.672 L 21.102 23.006 L 17.849 23.006 L 11.383 13.757 Z" fill="rgb(255, 255, 255)" height="24.5274px" id="bTanG43xy" width="24px"/></g></svg>)
