--- title: "Our Data Methodology: How We Count Events and Cities" description: "A transparent explanation of how events and cities are defined, counted, normalized, deduplicated, reviewed, and updated in MeetWho data. Use this methodology to understand what each figure represents, how edge cases are handled, and where limitations may apply." canonical: "https://meetwho.app/blog/data-methodology-events-cities" language: "en" published: "2026-08-18T01:47:22.262+00:00" updated: "2026-08-18T01:47:22.631998+00:00" reading_time_minutes: "17" source: "MeetWho — the networking layer for events and communities" license: "Quote with attribution and a link to the canonical URL." --- # Our Data Methodology: How We Count Events and Cities ## TL;DR - This data methodology is intended to explain the principles behind event and city counts presented by MeetWho. - Clear definitions matter because everyday language can hide important differences. - The most important question in any event counting methodology is the unit being counted. - MeetWho event totals are intended to represent distinct event occurrences within the scope of the figure being published. - At the methodology level, an event must represent a distinct scheduled event occurrence within the scope of the published data. ## Key questions **What Our Data Methodology Covers?** This data methodology is intended to explain the principles behind event and city counts presented by MeetWho. It covers the meaning of an event record, the distinction between an event and an event series, the role of location data, and the way common edge cases should be interpreted when a published total is reviewed. **How We Count Events?** MeetWho event totals are intended to represent distinct event occurrences within the scope of the figure being published. The goal is to avoid inflating an event count with attendee activity, internal interactions, or multiple records that refer to the same underlying occurrence. **What Counts as an Event?** At the methodology level, an event must represent a distinct scheduled event occurrence within the scope of the published data. The event may be in person, online, or hybrid, provided that the specific statistic being reported includes that event format. **What We Do Not Treat as Separate Events?** Applications and approvals: reviewing or approving participants does not create a new event. Waitlist activity: changes in waitlist status remain part of the same event. **How Recurring and Multi-Day Events Are Counted?** Recurring events and multi-day events describe different situations and should not be treated as the same thing. A multi-day event is one event that continues across more than one calendar day, while a recurring series consists of separate scheduled occurrences connected by a shared name, organizer, community, or program. **How We Count Cities and Event Locations?** City counting methodology should answer a different question from event counting: which physical places are represented by the events in scope? A city total therefore should not be read as the number of events, attendees, organizers, or users. ## Full article Title: "Data Methodology: How We Count Events and Cities | MeetWho" Description: "Explore MeetWho’s data methodology for counting events and cities, including scope, deduplication, location rules, updates, quality checks, and limits." # Our Data Methodology: How We Count Events and Cities **Data methodology,** in this guide, explains how MeetWho defines event and city data, how published figures should be interpreted, and where counting decisions can affect the numbers you see. The purpose is simple: when MeetWho refers to a number of events or cities, readers should understand what that figure represents—and what it does not. MeetWho combines event creation, participant registration and management, and consent-based networking in one platform. Organizers can create event pages, collect registrations and manage attendance, while participants can opt into professional networking designed around a simple idea: **know who to meet**. This methodology page focuses specifically on event and location data rather than networking recommendations, participant matching, messages, private notes, or other product activity. > **Methodology note:** Published figures should always be read together with their stated scope, reporting period, and any accompanying methodology notes. Event and city totals may describe different dimensions of the same underlying event activity and should not automatically be treated as interchangeable. ## What Our Data Methodology Covers This **data methodology** is intended to explain the principles behind event and city counts presented by MeetWho. It covers the meaning of an event record, the distinction between an event and an event series, the role of location data, and the way common edge cases should be interpreted when a published total is reviewed. The methodology does not treat every activity inside MeetWho as an event. Participant registrations, applications, QR check-ins, networking recommendations, connection requests, messages, notes, reminders, and other attendee interactions are separate product actions. They should not be confused with the number of events represented in an event-level statistic. The same principle applies to cities. A city count is a geographic measure, not a proxy for attendance, networking activity, organizer volume, or the number of people using MeetWho in that location. Whenever MeetWho publishes a city-based figure, the relevant location definition should be considered alongside the event count. ### Key Definitions Before You Read the Numbers Clear definitions matter because everyday language can hide important differences. A three-day conference, a weekly meetup series, and an online workshop may all be described casually as “events,” but a methodology needs more precise units. Term Methodology meaning Why it matters Event A distinct event-level record represented within the scope of the published MeetWho figure Establishes what can contribute to an event total Event occurrence A specific scheduled instance of an event or event series Helps distinguish individual dates from a broader recurring concept Event series A group of related event occurrences presented as part of the same recurring program or concept Prevents a recurring series from being confused with a single date City The city-level location associated with an in-person event according to the location information used for that event Establishes the geographic unit behind city-based reporting Online event An event designed to take place without a required physical venue Separates virtual participation from physical city attribution Hybrid event An event combining an online component with a physical event location Requires event counting and city attribution to be considered separately Duplicate record More than one record that appears to refer to the same underlying event occurrence Matters because duplicate records can overstate totals if they are not identified These definitions are designed to keep event-level and geographic reporting understandable. They do not imply that every edge case can be resolved from a title or venue name alone. Dates, locations, event status, organizer information, and record context may all be relevant when an apparent duplication or classification issue is reviewed. ### The Unit of Analysis The most important question in any **event counting methodology** is the unit being counted. For event totals, the relevant unit is the distinct event-level occurrence represented within the scope of the published figure—not the number of registrations, attendees, sessions, networking matches, or messages associated with that event. That distinction is especially important for larger conferences and community programs. One event can contain many participants, multiple agenda sessions, repeated interactions, and numerous networking connections without those activities automatically becoming additional events. Event counts therefore describe event activity at the event-record level rather than the volume of engagement taking place inside each event. ## How We Count Events MeetWho event totals are intended to represent distinct event occurrences within the scope of the figure being published. The goal is to avoid inflating an event count with attendee activity, internal interactions, or multiple records that refer to the same underlying occurrence. Where an event belongs to a recurring series, spans multiple days, changes status, or appears more than once, the relevant classification rules must be considered before interpreting the final total. This distinction makes the number more useful. A figure such as “events across multiple cities” should describe the events themselves and their location coverage, rather than combining fundamentally different measurements such as registrations, check-ins, or networking interactions. ### What Counts as an Event? At the methodology level, an event must represent a distinct scheduled event occurrence within the scope of the published data. The event may be in person, online, or hybrid, provided that the specific statistic being reported includes that event format. A single event can support many organizer and participant actions inside MeetWho. An organizer may collect registrations, review applications, manage a waitlist, send reminders, use QR check-in, or configure networking privacy settings. Participants may create professional profiles, receive relevant networking suggestions, send connection requests, and follow up after the event. Those activities enrich the event experience, but they do not by themselves create additional event units. The practical principle is: **one event-level occurrence should not become multiple counted events simply because many actions happen within it.** ### What We Do Not Treat as Separate Events To keep the counting unit consistent, the following types of activity should not be interpreted as additional events merely because they occur inside an existing event: - **Participant registrations:** multiple registrations increase attendance activity, not the number of event occurrences. - **Applications and approvals:** reviewing or approving participants does not create a new event. - **Waitlist activity:** changes in waitlist status remain part of the same event. - **Check-ins:** each QR check-in represents attendance activity, not another event. - **Networking recommendations:** personalized introductions are participant-level networking outputs. - **Connection requests and messages:** conversations between attendees do not alter the event count. - **Private notes and reminders:** personal follow-up tools remain associated with the participant’s networking workflow. This separation is essential when interpreting MeetWho data. Event totals answer a different question from participant totals, engagement metrics, or networking activity. A methodology that mixes those units would make comparisons difficult and could create a misleading picture of how many actual events are represented. ### How Recurring and Multi-Day Events Are Counted Recurring events and multi-day events describe different situations and should not be treated as the same thing. A multi-day event is one event that continues across more than one calendar day, while a recurring series consists of separate scheduled occurrences connected by a shared name, organizer, community, or program. This distinction matters because counting every calendar day as a separate event could overstate activity for conferences, retreats, accelerators, or workshops that intentionally run across several days. Conversely, treating an entire recurring program as a single occurrence could understate how often people actually have an opportunity to attend. #### Recurring Event Series For any published MeetWho statistic involving recurring events, the applicable counting rule should be based on the event occurrences represented in that dataset rather than the series name alone. Separate dates should not automatically be merged simply because they share branding, and records should not automatically be separated simply because their dates differ. The relevant question is whether the records describe distinct scheduled opportunities to attend or the same underlying occurrence represented more than once. That distinction should be resolved before the records contribute to a final total. ##### Individual Occurrences Consider a community meetup held on three different dates. If the records represent three genuinely separate gatherings, the dataset should preserve that distinction rather than treating the shared meetup name as sufficient evidence that only one event exists. By contrast, multiple records referring to the same scheduled gathering require duplicate review rather than automatic addition to the total. The same logic applies when an event series changes venue, format, or registration details between occurrences. Series membership provides useful context, but the underlying scheduled occurrence remains the more important unit for interpreting an event count. ###### Exceptional Rescheduling Cases Rescheduling creates a special case because an event can appear under an original date and a replacement date without necessarily becoming two real-world occurrences. A methodology should therefore distinguish a new occurrence from an updated date for an existing one. Where MeetWho publishes data affected by rescheduling, readers should interpret the total according to the final event status and the specific scope of that dataset. An outdated record should not be assumed to represent an additional completed event merely because it contains a different date. ### Canceled, Postponed, and Rescheduled Events Canceled, postponed, and rescheduled events should be treated as separate statuses. A cancellation means the planned occurrence will not take place as scheduled. A postponement indicates that the occurrence has been deferred, while rescheduling generally associates the event with a replacement date or time. Whether these records appear in a particular statistic depends on the scope of that statistic. For example, a figure describing events created on a platform can legitimately have a different inclusion rule from a figure describing events scheduled to take place during a particular period. For that reason, published MeetWho figures should identify their scope rather than implying that one status rule applies universally to every dataset. This is also why historical totals may need context. Event status can change after an event is first created or published, so a methodology should preserve the distinction between the state of the record at a particular point in time and its later status. ### Online and Hybrid Events Online events can contribute to an event total without necessarily contributing to a physical city total. Their defining characteristic is that participation does not require a single in-person venue, so assigning them to a city solely to increase geographic coverage would blur the difference between event format and physical location. Hybrid events require a more nuanced interpretation. A hybrid event may have a physical venue as well as an online participation option. In that case, its event-level classification and its geographic classification answer different questions: the event can exist as one occurrence while still being associated with a physical city where the in-person component takes place. Scenario Event-level interpretation City-level interpretation In-person event Distinct scheduled occurrence Associated with its applicable physical city Multi-day event Evaluated as one underlying occurrence unless the schedule represents separate events Based on the applicable event location Recurring series Individual occurrences must be distinguished from the series itself Each occurrence follows its applicable location Online event May be included when the reported scope includes online events Should not be assumed to represent a physical city Hybrid event Evaluated as an event occurrence Physical location can be considered separately from the online component Duplicate listing Requires review before contributing another event unit Should not create extra geographic coverage by duplication Rescheduled listing Must be distinguished from a genuinely new occurrence Uses the applicable location for the resulting occurrence The table is an interpretation framework rather than a substitute for the scope statement attached to a particular MeetWho statistic. If a dataset is restricted to in-person events, for example, online events would naturally fall outside that dataset even though they may exist elsewhere on the platform. ## How We Count Cities and Event Locations **City counting methodology** should answer a different question from event counting: which physical places are represented by the events in scope? A city total therefore should not be read as the number of events, attendees, organizers, or users. Multiple events can be associated with the same city, while some event formats may have no meaningful physical-city attribution at all. The safest interpretation is to treat city data as a geographic dimension attached to qualifying event records. A city should be counted because relevant event-location information supports that attribution—not because an organizer, participant, or company happens to be based there. ### How a City Is Assigned to an Event For an in-person event, the useful geographic reference is the location of the event itself. Organizer headquarters, participant home locations, billing details, networking profiles, and other unrelated geographic signals should not be treated as substitutes for the event location. Location information can also change as an event is edited. If a venue changes before the event takes place, the city associated with the event may likewise require correction. This is one reason location statistics should be interpreted according to the relevant reporting date and methodology version rather than assumed to be permanently fixed. ### How We Normalize City Names **City normalization** is the process of treating equivalent location labels consistently so that spelling differences do not automatically create artificial geographic distinctions. Real-world location data may contain abbreviations, alternative spellings, transliterations, punctuation differences, or different ways of expressing the same place. Normalization should not, however, collapse genuinely different geographic units simply because they are nearby or commonly associated with one another. A municipality and its wider metropolitan region are not automatically the same geographic concept. When MeetWho publishes city-level figures, the geographic unit used by that figure should therefore remain explicit. #### City Versus Metropolitan Area “City” and “metropolitan area” can produce very different totals. A metropolitan area may contain several independently governed cities or municipalities, while a city-level statistic may assign each event to the specific locality associated with its venue. MeetWho city figures should therefore be described according to the geographic level actually represented in the underlying data. Readers should not reinterpret a city count as metropolitan-area coverage unless the accompanying methodology explicitly says that metropolitan aggregation has been applied. #### Online, Hybrid, and Locationless Events An online event can be part of an event count without creating a physical city attribution. Hybrid events, meanwhile, may have a valid city when an in-person venue exists. This separation prevents virtual participation from being mistaken for geographic presence. Where an event does not have a meaningful physical location, it should not be assigned to a city merely to complete a geographic field. Preserving that distinction improves the usefulness of both event totals and city coverage figures. ##### Multiple Physical Locations Some event formats can involve more than one physical venue. In these cases, readers should not assume that one event necessarily produces only one city-level relationship. The applicable reporting rule should depend on the scope of the published statistic and the location structure recorded for that event. Any MeetWho dataset that includes multi-location events should state whether it counts unique cities represented, primary event locations, or another defined geographic unit. This prevents a single complex event from being interpreted inconsistently across reports. ## How We Prevent Double Counting **Data deduplication** is the process of identifying records that may refer to the same underlying event occurrence before those records are interpreted as separate events. Duplicate prevention matters because two records in a system do not necessarily represent two real-world events. Potential duplicates should be assessed using the information available for the event rather than title similarity alone. Dates, organizer context, venue details, event URLs, status information, and other relevant attributes can help determine whether two records describe distinct occurrences or the same event represented more than once. ### What Makes Two Records Potential Duplicates? Two records may warrant review when several identifying details overlap. However, events with similar names should not automatically be merged. A recurring meetup, for example, may legitimately use the same title every month while representing separate scheduled occurrences. The opposite is also true: the same occurrence may appear under slightly different wording after an edit, rescheduling action, or duplicate creation. Deduplication therefore depends on context, not a single field. ### How Duplicate Records Are Resolved The purpose of duplicate resolution is to preserve the most accurate representation of the underlying event without artificially increasing event or city totals. The exact treatment may vary according to the data source and record state, so published figures should follow the documented rule applicable to that dataset. Where a duplicate is identified, it should not create an additional event merely because another record exists. Likewise, duplicate location data should not create false geographic coverage. ## Data Sources, Updates, and Quality Controls MeetWho data can include information created or maintained through event workflows on the platform. Any published statistic should make clear which records are included and whether additional data sources are involved. If external geographic, mapping, or standards-based sources are used for location normalization, those sources should be identified in the relevant methodology documentation rather than implied. MeetWho should not attribute a location rule to ISO, IANA, a mapping provider, or another external system unless that dependency is actually part of the process. ### How Often the Data Is Updated Event data is not necessarily static. Organizers may update dates, venues, formats, or event statuses, and those changes can affect how a record should be interpreted. For that reason, any figure that depends on a particular snapshot should include a reporting or review date where appropriate. If a fixed update cadence applies to a specific dataset, that cadence should be stated alongside the published figure. ### Data Validation and Quality Assurance Quality control should focus on whether records are internally consistent and suitable for the statistic being reported. Relevant checks may include field validation, duplicate review, status verification, location review, and corrections supplied through legitimate event-management workflows. No validation process eliminates every possible error. The value of a methodology lies partly in making those limitations visible and giving readers enough information to understand how corrections may affect results. ## Known Limitations of the Methodology Event data can change after initial creation. A venue may move, an event may be postponed, a recurring occurrence may be edited, or a record may later be identified as a duplicate. These changes can affect historical or current totals depending on how a particular report is defined. Location data also contains real-world ambiguity. City names can have spelling variants, administrative boundaries can differ from common usage, and online or multi-location formats may not map neatly to one physical city. A city count should therefore be interpreted as a structured geographic measure within the stated methodology—not as a perfect representation of every way people describe a place. Readers should also avoid comparing two MeetWho figures unless their scopes are compatible. A count of events created, events scheduled, events held, or events included in a particular reporting period can answer different questions even when all are valid. ## Worked Examples of Event and City Counting The following examples are illustrative. They show how the methodology should be interpreted rather than documenting a hidden counting threshold or proprietary rule. Example Event interpretation City interpretation A conference runs Friday through Sunday at one venue Treat the underlying scheduled conference separately from its number of calendar days Associate it with the applicable event city A meetup takes place on three separate monthly dates Evaluate the three scheduled occurrences separately from the overall series Each occurrence follows its event location A workshop is fully online It may be included where online events are in scope Do not assume a physical city A hybrid event has a venue plus an online stream Evaluate the event occurrence independently of participation mode The physical component may support city attribution The same event is represented by two overlapping records Review for duplication before treating both as separate events Duplicate records should not inflate city coverage These examples reinforce a central principle: event counting and city counting are related, but they are not the same measurement. ## Why Transparent Event Data Matters A methodology page should make numbers easier to interpret, not simply make them look authoritative. Clear definitions help researchers, organizers, journalists, partners, and participants understand what a published figure can legitimately support. MeetWho combines event creation, participant management, and consent-based networking intelligence. Its approach is built around **“Know who to meet”**: helping people identify relevant connections rather than maximizing the number of contacts they collect. Transparent event data supports that broader principle by keeping the underlying context understandable. ## Data Methodology FAQ ### What is MeetWho’s data methodology? MeetWho’s **data methodology** explains how event and city figures should be defined, interpreted, and qualified. It separates event-level records from participant activity, distinguishes event totals from geographic coverage, and documents edge cases such as recurrence, online formats, duplicates, and changing event statuses. ### What counts as one event? The relevant unit is a distinct scheduled event occurrence within the scope of the published figure. Registrations, check-ins, messages, networking recommendations, and other participant actions do not automatically create additional event units. ### How are recurring events counted? A recurring series should be distinguished from its individual scheduled occurrences. Separate dates may represent distinct events, while multiple records referring to the same underlying occurrence should be reviewed for duplication. ### How are multi-day events counted? A multi-day duration does not by itself mean that each calendar day is a separate event. The underlying event structure determines whether the schedule represents one event occurrence or several distinct events. ### How are online and hybrid events treated? Online events may contribute to event totals when they are within scope, but they should not automatically create physical city coverage. Hybrid events may have a city attribution when a genuine in-person location exists. ### Can event or city counts change? Yes. Event dates, statuses, venues, and duplicate classifications can change over time. Published figures should therefore be interpreted according to their reporting scope, methodology version, and relevant review date. ## Methodology Changes and Revision History Methodology documentation should be updated whenever a material counting rule changes. Each published version should include an effective date, a last-reviewed date, and a concise description of any change that could affect how historical or future figures are interpreted. Version Effective date Change Impact 1.0 To be confirmed at publication Initial published methodology Establishes the baseline for event and city counting ### Questions or Corrections If you identify a possible issue in a published MeetWho figure, use the verified contact or support route provided on MeetWho so the relevant record or methodology can be reviewed. Do not rely on an unverified third-party source to correct platform data. Planning an event of your own? **Create an event with MeetWho for free**, manage participant registrations, and help opted-in attendees move beyond collecting contacts toward knowing who to meet for more meaningful professional conversations. --- Canonical HTML version: https://meetwho.app/blog/data-methodology-events-cities Machine-readable site index: https://meetwho.app/llms.txt