Registration Address Validation - Joomla Extension

Guide to Configuring and Testing Registration Address Validation for Joomla

Registration Address Validation is a niche Joomla extension built for a problem that is often underestimated until the first wave of junk registrations hits: the site accepts a user profile, but the address inside it turns out to be incomplete, oddly written, or clearly unusable for anything that follows. In this guide, we will focus not on a product pitch, but on practical use: where an extension like this makes sense, how to prepare your site, which settings to verify after installation, how to test registration, and what to do if address validation gets in the way of real users.

This article is written for site owners, Joomla administrators, and developers who tie registration to a directory, a restricted area, applications, subscriptions, a B2B account area, or any other scenario where address data matters. The exact tab names in your version of the extension may differ, so the steps below are built around Joomla-safe logic: install the package, enable the plugin or component, map the fields, run test registrations, verify the result, and carefully roll back any questionable settings.

The core idea is simple: address validation should not turn into a barrier for legitimate users. A good setup filters out obviously bad data while still leaving room for real addresses with unusual formatting, local abbreviations, multiple languages, and manual corrections.

Where This Extension Actually Helps

Registration Address Validation makes sense when the address in the user profile affects what happens next. If registration is only used for comments or access to a restricted article, strict address validation may be unnecessary. But if the site stores applications, routes users by region, prepares documents, passes data to a manager, or checks access by territory, address quality becomes part of the workflow.

This matters even more in Joomla because registration usually sits at the intersection of several systems: the built-in Users component, profile plugins, custom fields, the site template, anti-spam protection, email notifications, and sometimes external CRMs or delivery services. If one field is recorded incorrectly, the problem may not show up during registration at all, but later during manual review, data export, or an attempt to contact the user.

Common Use Cases

In practice, the extension is useful across several types of projects. One scenario is a restricted-access site where the administrator needs to understand which region a user comes from. Another is a service directory or partner portal where the address affects how an application is routed. A third is a registration form for a local community, educational project, club, or association where it is important to separate legitimate applications from automated junk. A fourth is a site where the user profile is later used in documents, emails, or reports.

• For a B2B site, the address helps distinguish a real company from a random registration.
• For a regional portal, validation reduces the number of profiles with an empty city or a random string instead of an address.
• For a private club, address checks help the moderator make a faster decision on an application.
• For a site with manually processed orders, a valid address reduces the number of follow-up emails.

That said, the extension should not be treated as your only security tool. It works at the level of input quality. Bots should be handled by other mechanisms: Joomla's built-in CAPTCHA, email verification, registration restrictions, anti-spam plugins, activity logs, and manual moderation.

When Strict Validation Is a Bad Idea

Some sites are hurt more than helped by strict address validation. For example, if your audience is international, address formats may vary widely. In some countries, there is no familiar split into street, house number, and ZIP code, and users may enter addresses in Latin script, Cyrillic, or their local language. If the extension is configured too aggressively, real people will simply see a rejection and abandon the form.

Practical rule: enable validation on a staging site first, or use a soft mode if your version supports it. A hard registration block should only be turned on after a round of tests using real address formats from your audience.

What the Sources Confirm and How to Read This Guide

The original link points to a Kuneze product page at /downloads/rav4, and the task type identifies it as a Joomla extension. During research, the page was not accessible through the browser tool, so this article cannot honestly claim the exact names of all settings, current compatibility, price, license, archive contents, or whether it integrates with an external address verification service. Those uncertain details are listed in notes.txt.

Because of that, this guide is deliberately cautious. It explains how to safely introduce an extension of this class into Joomla, which checks to run, and which decisions to make before enabling it on a live site. Where the guide discusses Joomla as a platform, it follows general official principles: installing extensions through the admin panel, enabling plugins, working with users, custom fields, access permissions, cache, and language strings. Where it discusses Registration Address Validation specifically, the wording stays limited to what is supported by the product name and the task type: validating address data during registration.

How to Tell a Confirmed Fact from Practical Advice

This article operates on two levels. The first is factual: the product is a Joomla extension connected to registration and address validation, and its original page is hosted on the Kuneze website. The second is methodological: how to introduce this kind of tool without breaking registration, which tests to run, which conflicts are common in Joomla forms, and how to diagnose issues. The methodological guidance does not pretend to be hidden product documentation. It is based on safe Joomla practice.

If, after downloading the extension, you discover that its interface differs from the scenario described here, use this guide as a validation map: find the matching settings in your admin panel, check the fields, repeat the test registrations, and compare the outcome. Do not move the setup to a live site until you understand how the extension behaves with invalid, edge-case, and valid addresses.

Preparing the Site Before Installation

Preparation matters not because installing a Joomla extension is inherently difficult. The real issue is that address validation sits directly in the registration flow, which means it can stop account creation. Any mistake in that part of the process immediately affects conversion, support, and user trust. So before anything else, you need to understand your current registration form, the field set it uses, and exactly where the address is used after the account is created.

Review Your Current Joomla Registration Flow

Open the admin panel and look at how users are currently handled. In a typical setup, you should review the global registration settings, the status of the profile plugin, custom fields, and the menu item that leads to the form. If registration is closed, the extension may install correctly but you will not be able to test the user flow. If registration is open but the address fields were added by a third-party component, you need to understand which specific fields are supposed to be validated.

• Make sure user registration is enabled in Joomla settings if the site is supposed to accept new accounts.
• Check where the address is stored: in the standard profile, custom fields, a community component, an application form, or an integration.
• List the required address parts: country, region, city, street, house number, ZIP code, and any additional line.
• Mark the fields that should not be required for every country and every type of user.
• Prepare test addresses: one valid, one incomplete, one with an unusual format, one in another language, and one obviously junk string.

Create a Safe Rollback Point

Before installing any extension that affects registration, you need a safe path back. At minimum, that means a fresh backup of both files and the database. A better option is a staging copy of the site where you can enable the extension, run registrations, and inspect logs without live traffic pressure. If the site already receives registrations every day, do not enable strict validation during business hours without testing first.

Quick takeaway: before installation, you should have a backup, a list of address fields, a set of test addresses, and a clear understanding of who on the site is responsible for manually reviewing questionable registrations.

Account for the Template, Cache, and Anti-Spam Layer

The extension may work correctly, yet the user can still run into problems because of the site template or caching. For example, an error message may be hidden by CSS, the form may be cached, or an anti-spam plugin may stop registration before address validation has a chance to return a useful result. That is why preparation should cover not just the field list, but the entire user path from opening the form to receiving the activation email.

If aggressive page caching is enabled on the site, exclude the registration page from full-page cache, or at least test it as a guest after clearing the cache. Registration forms generally work best when the user is not exposed to stale tokens, outdated messages, or accidentally resubmitted forms.

Installation and Initial Enablement Without Breaking Registration

Installing Registration Address Validation starts like any normal Joomla extension install: the administrator receives the archive, opens the extension installer, and uploads the package. But this is the point where you should slow down. Extensions that sit inside the registration chain often add a component, a plugin, language files, or additional parameters, and enabling only one part may produce incomplete results.

Safe Installation Sequence

1. Open the Joomla admin panel using an account with permission to install extensions.
2. Go to the extension installer and upload the product ZIP archive.
3. After installation, review the Joomla message that appears. It usually indicates whether the package was installed completely.
4. Open the list of extensions or plugins and find the items related to Registration Address Validation or Kuneze.
5. Enable the required plugin or component only when you are ready to run a test registration.
6. Clear the Joomla cache and any external cache layer if one is present.

If the extension installs successfully but you do not see it where you expected, do not enable every similar-looking plugin at random. First confirm that the archive is intended for your Joomla branch, that installation completed without errors, and that your administrator account has permission to view components, plugins, and settings.

First Check After Enabling

Right after enabling the extension, do not rush into filling out every setting. First confirm that the site still opens the registration form, that the form submits, and that the user receives a clear message. Run two registrations: one with a normal valid address, and one with an obviously invalid string. If both behave the same way, the extension is not yet affecting the process or has not been mapped to the correct fields. If both are blocked, the setup is too strict or conflicts with the form.

What success looks like: after enabling the extension, the user should either proceed with registration successfully or see a clear message explaining which part of the address needs to be corrected. A blank page, an empty message, or a silent return to the form is a problem, not normal validation behavior.

Configuring Address Fields and Validation Rules

The most important part of configuration is mapping the site's real fields to the validation logic. Even a solid extension cannot validate an address if it reads the wrong fields, receives empty values, or does not understand the format used by your registration form. That is why configuration should be driven not by a vague desire to "make things stricter," but by a concrete question: which data does the site actually need, and at what point should the user be required to fix an error?

Mapping Profile Fields

If your version of Registration Address Validation includes field selection settings, start there. The city field must point to the actual city field, the ZIP field to the ZIP field, and the country field to the country field. You cannot feed one large free-text "Address" field into every role if the extension expects separate parts. That approach creates false errors and makes diagnosis nearly impossible.

For a typical site, it makes sense to split the setup into required and optional elements. Country and city are often enough for baseline validation. ZIP code becomes useful when the site deals with shipping, documents, or regional moderation. Street and house number are not always necessary: for some registrations, city and region are enough, and asking for too much detail reduces the user's willingness to sign up.

The table helps you choose a starting point, but it does not replace testing. Address data is highly varied, and overly rigid logic tends to break on real-world examples.

Strict vs. Soft Validation

If the extension offers different strictness levels, start with the softer one. A soft mode is usually better for data collection: it may prompt the user to correct the address without blocking registration in every borderline case. A strict mode makes sense when an incomplete address immediately makes the registration useless or risky for the workflow. For example, if an application goes straight into processing after signup, it is better to stop an obviously invalid address earlier.

Overly strict validation typically creates three problems. The user does not understand what needs to be fixed. Legitimate addresses with local quirks fail the form. The administrator receives complaints but cannot see the real cause in the logs. That is why strict rules should be enabled gradually: first country and city, then ZIP code, then detailed address lines only where they are truly needed.

What Not to Enable Unless You Actually Need It

Do not make every address field required just because the extension allows it. Do not force a ZIP code for a country where users often do not know it. Do not block registration because of a single mismatch if the site does not depend on precise geocoding. Do not add external address verification unless you understand how it handles personal data and what happens when the service is unavailable.

Error Messages and Site Language

For users, the validation itself is only half the experience. The error text matters just as much. A message like "Invalid address" is not very helpful to a Russian-speaking visitor. If the extension uses Joomla language constants, it is better to translate them through language overrides rather than by editing the extension files directly. That way, the change survives updates and stays within Joomla's normal administration workflow.

The wording should be short and specific: "Check the city and ZIP code," "Add a house number," "Select a country from the list." Avoid accusatory language. The person may simply have made a mistake, copied the address from another document, or run into a format the extension failed to recognize.

How Address Validation Fits into the User Flow

To configure Registration Address Validation correctly, it helps to picture not the admin screen, but the full data path. The user opens the form, enters an address, Joomla receives the values, the extension checks them against its rules, and then registration either continues or returns an error message. If the site also uses email confirmation, moderation, or additional profile fields, those come after this step succeeds.

This chain matters for diagnosis. If the user cannot even see the form, the issue may be with the menu item or access permissions. If the form opens but does not submit, check the token, cache, template, and JavaScript. If the form submits but the address is not validated, the extension is probably not enabled or not mapped to the right fields. If the form blocks everything, review rule strictness, required fields, and the format of your test addresses.

Input - Product Logic - Output

For an extension like this, the practical chain looks like this. The input is a set of field values: country, city, ZIP code, and address line. The product logic compares them against configured rules or the available validation mechanism. The output is one of two states: registration continues, or the user sees an error. After that, the administrator should verify not only the front-end form, but also the saved user profile.

• Input: The real set of address fields in the Joomla registration form.
• Product logic: Validation of completeness, format, and consistency based on the extension's available rules.
• Output: Successful user creation or a clear stop with an error message.
• Verification: Review the profile in the admin panel, the activation email, and form behavior on resubmission.
• Failure symptom: A rejection without a clear message, valid addresses being blocked, or junk strings going unchecked.
• Fix: Revisit field mapping, relax a rule, clear cache, or check for a conflict with the template or anti-spam layer.

Why Testing Just One Address Is Not Enough

One successful test proves very little. It only shows that one specific combination of data made it through the form. A meaningful check requires a small set of addresses that reflects your real audience. Even if the site serves only one country, test different city spellings, ZIP codes with and without spaces, house numbers with building additions, extra address lines, and Cyrillic input. If the site is international, include countries with different ZIP code and address-line formats.

This kind of testing shows where the extension truly improves data quality and where it starts getting in the way. If legitimate but slightly unusual addresses are rejected too often, it is usually better to relax the rule and leave those cases for manual review than to lose registrations.

Practical Example: Validating Registration for a Private Directory

Consider a scenario that fits Registration Address Validation well: a Joomla site accepts applications for a private supplier directory. The user registers, enters the company address, confirms their email, and the administrator later reviews the profile and grants access to additional sections. The goal is not to build a perfect geographic database, but to filter out obviously bad addresses and speed up manual moderation.

Goal and Preparation

The goal of this example is to make sure a user cannot submit an empty or meaningless address, while still allowing registration with a real address even if it includes a building, office number, or unusual wording. Before you begin, Joomla registration should already be enabled, the address fields should be prepared, and the extension should be installed. You also need a test mailbox, because the activation email or admin notification helps confirm that the registration chain is still intact.

Configuration Steps

1. Open the extension settings or the related plugin settings and find the address field options.
2. Map the country field to the real country field in the registration form.
3. Map the city and ZIP code fields if your moderation workflow uses them.
4. Keep the additional address line relatively flexible if users may enter a building, office, or note there.
5. Configure the error message through the extension settings or a Joomla language override.
6. Save the settings and clear the site cache.
7. Open the registration form in a private browser window as a normal guest.

After saving, do not limit your checks to the admin panel. Address validation exists for the public form, so the test should be run from the outside. If the site has multiple registration menu items, test the one real visitors actually use.

Test with a Valid Address

Start by filling out the form with legitimate data. Use an address that matches your audience and does not rely on unusual abbreviations. After submission, verify three things: the user was created or received an activation email, the address was saved in the profile, and the admin panel shows no errors. If all three are true, the basic chain is working.

Test with an Invalid Address

Now repeat the registration using an obviously bad address: an empty city, a random string in the ZIP code, or a line that does not resemble an address at all. A good outcome is that the form stops registration and shows a clear message. A bad outcome is that registration goes through without warning or the user sees a blank page. In the first case, validation is not connected to the right fields. In the second, you need to inspect the conflict, the error message, or the server log.

One nuance: if the extension blocks a legitimate address, do not rush to disable the product entirely. First relax the specific rule, review the message language, and repeat the test with several real-world examples.

Verifying the Result After Launch

Once testing succeeds on a site copy or during a safe maintenance window, you can enable the extension on the live site. But launch does not end when you click Save. The first registrations after enablement should be reviewed manually. The goal is to confirm not just that the form blocks some users now, but that the data quality has actually improved.

What to Check in the User Profile

Open several newly created users in the admin panel and verify how the address fields were saved. Look not only for empty values, but also for signs of incorrect mapping. For example, the city may have landed in the region field, the ZIP code may have ended up in the address line, or the country may be blank. These errors are especially common when registration is assembled from multiple extensions or custom fields.

• The address fields are saved in the expected parts of the profile.
• The user sees a clear error message when the address is invalid.
• Registration and activation emails still go out.
• The administrator can understand why a specific registration was stopped.
• The form does not break after cache clearing, a language switch, or resubmission.

How to Evaluate the Benefit After a Week

Do not measure success only by the number of rejected registrations. Compare profile quality before and after the extension was enabled. If you see fewer empty cities, meaningless ZIP codes, and one-word addresses, the configuration is doing its job. If support requests go up, users complain about unclear rejections, or administrators start creating users manually to work around the form, the rules need to be softened.

For projects with manual moderation, it helps to keep a short observation table: date, symptom, address part, and resolution. This does not have to live inside Joomla. A simple internal note is enough to reveal recurring problems after a few days and let you change one specific rule instead of the entire configuration.

Safe Message Localization and UX Improvements

If users are seeing confusing messages, start with Joomla's built-in language overrides. That is safer than editing the extension files: a product update will not wipe out your changes, and the administrator can find the text in one place. The exact language constants need to be checked in the installed extension because no public documentation was found.

How to Improve Error Text Without Editing Code

Open the Joomla language overrides section, select the site language, and search for the error string using a fragment of the text the user sees. If you find the constant, replace the text with something clearer. Good wording tells the user what to fix without exposing unnecessary technical logic. For example, "Check the city, ZIP code, and house number" is better than "Address validation failed."

After adding the override, repeat the registration test. If the text does not change, clear the cache, verify the correct language, and make sure the message actually comes from the extension rather than another form plugin. If you cannot find the constant, do not edit the product files blindly. Record it as a limitation and check the developer's documentation or support.

A Small CSS Tweak for Message Visibility

If the message exists in the HTML but is hard to see because of the template, you can add a safe CSS adjustment to the template's custom stylesheet. The message class on your site may differ, so inspect the markup in browser developer tools first. The example below shows the general approach and does not depend on the extension's internal files.

.com-users-registration .alert,
.com-users-registration .system-message-container {
  border-left: 4px solid #d9480f;
  padding: 12px 16px;
  line-height: 1.5;
}

The test is simple: submit the form with an invalid address and make sure the message is visible above the form or next to the problematic field. The rollback is simple too: remove the CSS change from the template's custom file. Do not edit Joomla core files, the stock template files, or the extension files themselves.

Limitations, Compatibility, and Data Privacy

Address validation may sound like a minor technical detail, but it affects both personal data and the user journey. That is why it is important to understand its limits. The extension may improve input quality, but it does not guarantee that a person actually lives at the address they entered. It does not replace legal verification, moderation, document checks, delivery validation, or manual work by a manager.

Compatibility with Custom Fields and Profile Components

If the address is stored in Joomla's standard custom fields, diagnosis is usually easier because you can see which fields are required and where they are saved. If the address is created by a third-party profile component, community extension, form builder, or directory, you need to verify whether Registration Address Validation can work with that specific data source. Without confirmation, you should not assume full compatibility.

A good test is to create a user through the public form and then open the profile in the admin panel to see where the values ended up. If the extension validates only the standard registration flow while your site uses a separate registration component, the check may not work at all. In that case, it is better to look for integration details in the developer's documentation or keep the extension limited to Joomla's standard flow.

Cache, Optimization, and Plugin Order

The registration page needs a fresh form token and proper message rendering. Full-page cache, aggressive JavaScript optimization, or script bundling can sometimes interfere with forms. If users start seeing repeated errors after validation is enabled, disable cache only for the registration page or temporarily turn off optimization to compare behavior.

Plugin order can matter too. Anti-spam, consent checks, user profile logic, and address validation may all fire on the same event. If you cannot tell which layer is stopping the form, temporarily disable only one questionable layer at a time and repeat the same test address. That is the fastest way to identify the real source of the problem.

Privacy and External Validation

If your version of the extension uses an external address verification service, evaluate separately which data is sent out and where that behavior is documented. Do not send unnecessary personal data unless there is a real need. For some sites, internal checks for completeness and format are enough, and address accuracy can be confirmed manually later. If the external check is unavailable, the form should behave predictably: show a message, allow the submission in soft mode, or let the administrator handle the application manually.

How It Connects to User Groups, Moderation, and the Admin Workflow

Address validation becomes especially useful when it is built into a clear administrative process. If the site simply blocks bad-looking strings but the administrator has no plan for handling borderline registrations, the setup remains incomplete. In Joomla, it is better to decide in advance what happens after a successful address check: does the user get access immediately, wait for email confirmation, land in a basic group, or need to be moved manually into another group?

The extension itself should not be turned into a moderation system unless it is actually designed for that. Its job is to help the form reject obviously bad address data. But around it, you can build a clean process: the user fills out the form, the address passes a basic check, the account is created with minimal permissions, the administrator reviews the profile, and only then grants access to restricted materials or a commercial area. This approach lowers the risk of accidentally granting access to someone with questionable data and does not require inventing unsupported product features.

How to Use User Groups Without Overcomplicating Things

In Joomla, user groups and access levels let you separate the fact of registration from the fact of approval for restricted content. That is useful if the address is needed to verify region, organization status, or eligibility for a closed program. Do not make address validation the only gatekeeper. It is usually better to create a base group for new users and a separate group for verified members if that model fits the site.

A practical workflow may look like this: Registration Address Validation helps the form accept only a complete and plausible-looking address, Joomla creates the user in the regular group, the administrator opens the profile, checks the address against internal rules, and then moves the user to the group with the required access level. In that workflow, the extension does not promise more than it should. It improves the input data, while the access decision remains with a person or a separate confirmed business process.

• For an open site, it is usually enough to check that the address is not empty and does not look like a random string.
• For a regional restricted section, it helps to verify city, country, and whether the address fits moderation rules.
• For a B2B directory, it is often better to route questionable cases to manual review instead of blocking every unusual address.
• For a multilingual site, do not automatically translate address values if they need to remain in their original form.

What the Administrator Should See After Registration

Good address validation should leave the administrator with a clear picture. The user profile should show the same address parts the user entered. If the full address is saved into one field, it becomes harder for the administrator to understand what was actually validated. If the fields are separated, it is easier to see where the user made a mistake: the country is selected, the city is present, the ZIP code looks odd, or the street is incomplete.

If you have several administrators, agree on a few simple handling rules. For example: do not silently edit an address without contacting the user, do not move a user into a restricted group based on a questionable address, do not delete a registration before checking the email, and do not treat one odd ZIP code as proof of bad faith. That kind of editorial discipline matters just as much as the technical setup.

A Mini Log for Questionable Addresses

Even if Joomla and the extension do not provide a dedicated address-validation log, you can keep a short internal note. It only needs to capture the symptom, the field, the action taken, and the outcome. After a few days, that note will start showing recurring issues: users from one country cannot pass the ZIP code check, the template hides the error, the moderator keeps correcting the same format, or the city occasionally lands in the neighboring field. That gives you material for precise tuning instead of guesswork.

This kind of log should not store more personal data than you actually need for diagnosis. Do not copy full addresses into a shared table if it is enough to record the error type and field. The less duplicate data you keep, the easier it is to maintain a clean process.

How Not to Damage Registration Conversion

Address validation is only useful when the user understands what is being asked of them. If the form suddenly becomes much longer, the message sounds harsh, and the error appears only after full submission with no field highlight, some people will leave. That is why Registration Address Validation should be treated not only as a technical filter, but also as part of the registration experience.

Ask Only for What You Actually Need

The more fields your registration form has, the more likely errors become. If the address is needed only for regional moderation, do not force every user to enter office details, building numbers, apartment entrances, and extra comments. If a full address is needed later, you can collect the basic region during registration and ask for the full details in the profile after login. This matters even more on sites where the user is not yet sure whether they want to stay.

In Joomla, it is often convenient to separate initial registration from later profile completion. In the first step, the user creates the account and passes a minimal address check. After login, the administrator or the user can complete the profile. If the extension validates only the registration form, do not try to make it solve every profile-related task at once.

Give Users a Hint Before They Hit an Error

The best error message is the one the user never needs to see. If the ZIP code field is required, show an example format next to it. If the address must fall within a certain country, explain that before the form is submitted. If the city must be selected from a list, do not place an unexplained free-text field right next to it. Small details like these reduce the number of rejections and make validation feel less harsh for real users.

Keep the hints short. Do not turn the registration form into a wall of instructions. One example and one clear limitation are usually enough. Additional detail can go into the FAQ, a short note near the form, or a support email.

Test the Form on Different Devices, but Do Not Design the Whole Workflow Around Mobile

Most Joomla administration happens on a desktop, but user registration may happen on a phone. So after configuration, test the form on a narrow screen: is the error visible, has the hint shifted out of place, and can the user fix the field without losing the data they already entered? At the same time, there is no need to design the entire setup around smartphones. The main goal is for the public form to be usable while the admin side remains clear on a working screen.

Practical conclusion: if validation reduces junk but sharply increases complaints, the problem is not the idea of validation itself. It is the balance between strictness, guidance, and the moderation process.

When Registration Address Validation Is the Right Choice

Registration Address Validation is worth using when the address in the user profile genuinely affects how the site operates: moderation, regional routing, restricted access, manual application review, or follow-up communication. The extension is especially useful when the real issue is not how polished the form looks, but the quality of the data the administrator receives after registration.

Before going live, run through a short checklist: you have a backup, the fields are mapped correctly, test addresses are ready, the error message is clear, the registration page is not being cached incorrectly, and borderline addresses are not being blocked without reason. After that, you can download Registration Address Validation and test the extension on your site copy.

If testing shows that the product does not work with your nonstandard registration form, do not try to patch Joomla core or the extension files to force it. It is safer to choose a profile-oriented or form-oriented solution that officially supports your scenario, or to leave address review at the manual moderation stage. A good setup here is measured not by how strict it is, but by how smoothly the user gets through registration and how useful the resulting data is to the administrator.