Categorize Scripts in optzi!

Categorizing a finding connects an approved script or iframe to a consent purpose. optzi! can then apply the rules for that category according to your visitor flow, region settings, and blocking configuration.

Important: A category is a configuration decision, not a legal conclusion. Recognized-service and AI suggestions are research aids only. Review each finding before approving it, and remember that saved rule changes are not live until you deploy them.

Before You Start

• Be an account owner. Owners can categorize, approve, or ignore findings; members can view the list but cannot make those changes.

• Run a static discovery scan and allow any pending classification suggestions to finish.

• Make a list of the tools you expect your site to use, including analytics, advertising, chat, video, forms, scheduling, and tag management.

• Have a private or incognito browser window ready for testing after you deploy the rules.

Understand the Categories

Choose the category that matches what the script actually does on your site:

• Necessary: Required to provide a core service the visitor requested, protect the site, or remember consent choices. Necessary scripts are always allowed, so use this category narrowly.

• Functional: Powers optional site features or preferences, such as chat, embedded media, scheduling, or enhanced interface behavior.

• Analytics: Measures visits, usage, performance, or other activity so you can understand and improve the site.

• Marketing: Supports advertising, retargeting, campaign attribution, profiling, or personalized promotion.

A vendor name is not a category. One service can load several resources for different purposes, and the same resource can be used differently on different sites. Categorize the behavior you have verified, not the brand name or file name alone.

Review and Categorize a Finding

1. In optzi!, open the site you want to review and select Scripts.

2. In Unreviewed findings, open the finding you want to investigate.

3. Review the available evidence: the script, iframe, or inline type; host and path or inline preview; pages where it appeared; source labels such as Seen at runtime; first- and last-seen dates; and any suggestion, confidence level, and reason.

4. Identify what added the resource. Check your site code, CMS plugins, tag manager, embedded tools, and the vendor's own documentation. If the finding came from a tag manager, trace it back to the individual tag.

5. Confirm what happens when the resource runs. Look for storage, network requests, identifiers, page features, and any additional scripts or iframes it creates.

6. Choose Necessary, Functional, Analytics, or Marketing from Choose category.

7. Approve the finding. optzi! moves the reviewed item into Script Inventory and prepares the matching rule change when scanner-backed fingerprint evidence is available.

Use Suggestions as a Starting Point

optzi! may show a recognized-service suggestion or an AI suggestion with a confidence level and short reason. Suggestions never approve or apply themselves, and the AI classifier cannot designate a script as Necessary. A low-confidence or uncategorized result means you need to investigate further; a high-confidence result still needs your review.

Inline scripts deserve extra care because their purpose may not be obvious from a short preview. Identify the plugin or feature that produced the code and follow the requests it launches before deciding.

Review Several Findings Together

Use the selection checkboxes when several findings have the same verified purpose:

1. Select the findings you have reviewed.

2. Choose Set all to and select the shared category.

3. Select Approve selected.

Do not use bulk actions merely because several items share a vendor. Separate analytics, functional, and marketing resources from the same service may require different categories.

When to Ignore a Finding

Ignore a finding only after you have deliberately decided that it should not create a consent rule. Ignoring records your review decision, but it does not create a blocking rule. It is not a substitute for investigating an unfamiliar resource.

If the resource's purpose or implementation changes later, review it again. New fingerprints or runtime observations can appear as new findings after a later scan.

What Happens After Approval

• optzi! creates or reuses a Script Inventory entry for the discovered fingerprint.

• When scanner-backed fingerprint evidence is available, optzi! prepares the matching exact consent rule for the approved category.

• Findings with the same fingerprint are linked so you do not need to approve every duplicate separately.

• A manually added inventory row is documentation only unless it has matching scanner evidence. Use an Advanced Rule when a stable vendor host or path is the match you need.

Important: Approval saves the rule configuration, but it does not update the installed widget by itself.

Deploy the Rule Changes

1. Review the pending rule count near the top of the Scripts page.

2. Confirm that automatic blocking is configured the way you intend.

3. Select Deploy changes or Deploy to activate.

4. Wait for the site to show that the latest configuration is active.

The deployed widget follows the category rules together with your consent behavior and regional settings. Necessary resources remain available; optional categories follow the choices presented to that visitor.

Test the Result

1. Open the site in a private or incognito window so an earlier consent choice does not affect the test.

2. Test the path where optional consent is denied. Confirm that the categorized resource behaves according to the selected visitor flow and is not running when its category should be off.

3. Grant the category and confirm that the expected feature or request starts working.

4. Withdraw the category, reload where necessary, and confirm that future loads follow the new choice.

5. Trigger lazy features such as chat, video, forms, and schedulers. Review any additional runtime scripts or iframes they load.

If a root script loads changing child files that an exact fingerprint does not cover, create the narrowest stable Advanced Rule for the required host or path. Avoid broad patterns that could catch unrelated resources.

Google Tag Manager Needs Separate Review

Google Tag Manager is a delivery mechanism. The container and the tags it launches can have different purposes, so do not assign one category to everything simply because it came through GTM. Review the container's role, inspect each important tag and trigger, add the appropriate consent requirements in GTM, and test with consent denied and granted.

Final Check

Before you finish, confirm that:

• Every approved category is based on the resource's verified purpose.

• You did not treat an AI suggestion as an automatic decision.

• Unknown or low-confidence findings were investigated rather than guessed.

• Pending rule changes were deployed.

• You tested denied, granted, and withdrawn consent states.

• Runtime child resources and tag-manager tags were reviewed separately where needed.

Related Article

• Run Your First Site Scan

Legal note: This article explains how to use optzi! and is not legal advice. Your obligations may vary by jurisdiction and implementation. Consult qualified legal counsel for advice about your situation.