SOP 2: Shopify App Research and Hands-On Testing

SOP Information

1. Purpose

The purpose of this SOP is to define how Blinto researches, installs, tests, evaluates, documents, and scores Shopify apps before creating review content.

This process ensures that every Shopify app review is based on credible evidence rather than copied product descriptions, assumptions, or unverified marketing claims.

The research process should help Blinto understand:

• What the app actually does
• How easy it is to install and configure
• Which merchants it is best suited for
• What limitations users may experience
• How its pricing and features compare with alternatives
• Whether its documentation and support are reliable
• How it may affect store operations, performance, and user experience
• What makes the app different from competing products

This SOP must be completed before the content brief or article draft is created.

2. SOP Objective

This SOP helps Blinto:

• Produce evidence-based Shopify app reviews.
• Build internal knowledge of the Shopify app ecosystem.
• Evaluate apps consistently across categories.
• Avoid unsupported claims and fake first-hand experience.
• Identify app strengths, limitations, and best-fit use cases.
• Collect useful screenshots and testing evidence.
• Understand common merchant experiences.
• Create reliable inputs for category, single-app, and comparison content.
• Protect Blinto’s credibility and editorial independence.

3. Scope

This SOP covers:

• App access and test-store preparation
• Installation and onboarding
• Core feature testing
• Dashboard and usability evaluation
• Pricing verification
• Integration and compatibility research
• Documentation and support review
• Merchant-feedback analysis
• Evidence and screenshot collection
• App scoring
• Technical validation
• Research storage and approval

This SOP does not cover:

• Keyword research
• Search-intent mapping
• Competitor content analysis
• Content outline creation
• Article writing
• Editorial editing
• Publishing
• Founder outreach
• Performance reporting

These activities will be covered in later SOPs.

4. Entry Requirements

SOP 2 begins only when:

• SOP 1 has been completed.
• The topic has been approved.
• The ClickUp task status is Approved for Research.
• The selected app or app list is confirmed.
• The content format is confirmed.
• The app category and target audience are defined.
• The topic proposal and app-selection sheet are attached.
• The assigned researcher and reviewer are confirmed.
• Testing access requirements have been reviewed.

The researcher must not begin testing an unapproved app unless the Project Lead provides written approval.

5. Expected Output

At the end of this SOP, the team must have:

1. A completed research file for every selected app.
2. A confirmed app-testing status.
3. Installation and onboarding observations.
4. Core feature-testing notes.
5. Verified pricing information.
6. Usability and merchant-fit observations.
7. Documentation and support findings.
8. Merchant-feedback patterns.
9. Screenshots or other approved evidence.
10. A completed app-scoring sheet.
11. Technical validation notes.
12. Clearly documented limitations.
13. A completed comparison matrix where required.
14. A research summary ready for content-brief creation.
15. An approved ClickUp status of Research Completed.

6. Roles and Responsibilities

One person may perform several roles during the validation phase, but testing and approval should not rely entirely on the same person when technical claims are involved.

7. Required Tools and Resources

The researcher may use:

• Shopify development store
• Shopify App Store
• App developer website
• App documentation or help center
• App demo environment
• App dashboard
• Screen-capture tool
• Screen-recording tool
• Browser developer tools
• Page-performance testing tools
• Google Sheets or Airtable
• ClickUp
• Blinto’s Shopify App Knowledge Base
• Approved test products, orders, and customer data
• App support channel where appropriate

Optional Tools

Depending on the app category:

• Shopify Theme Inspector
• Lighthouse or PageSpeed Insights
• Chrome DevTools
• Shopify Flow
• Test email or SMS account
• Sandbox payment gateway
• Test subscription products
• Test shipping profiles
• Test discount codes
• Analytics or event-monitoring tools

Only approved and safe tools should be used.

8. Testing Environment Rules

Use a Development or Approved Test Store

Shopify apps should normally be tested in a Blinto development store or another approved test environment.

Do not use a client’s live store unless:

• The client has provided written permission.
• The test is necessary.
• A rollback plan exists.
• Sensitive data is protected.
• The Project Lead approves the activity.

Test Store Preparation

Before installation, confirm:

• Store login works.
• Required permissions are available.
• Test products exist.
• Test collections exist where required.
• Test customers and orders are available where appropriate.
• A compatible theme is installed.
• The theme is backed up before app code changes.
• The store does not contain real customer data.
• The previous app test has been cleaned up.
• Baseline screenshots or performance results have been recorded when relevant.

Data Protection

Do not use:

• Real customer information
• Real payment details
• Confidential client information
• Unapproved personal data
• Production API keys
• Client-owned assets without permission

Use fictional or approved test information.

9. App Testing Levels

Every app must receive one of the following testing levels.

The testing level must be displayed in the internal research file.

The published content must not claim full testing when only partial or research-based evaluation was completed.

10. Complete Research and Testing Workflow

Step 1: Review the Approved Topic

Before testing, the researcher must review:

• Content type
• App category
• Selected apps
• Primary audience
• Merchant problem
• Main search intent
• Expected comparison criteria
• Relevant Blinto service connection
• App-testing status from SOP 1
• Approval notes
• Research deadline

Research Focus by Content Type

Output

A short testing plan showing what must be evaluated.

Step 2: Confirm App Identity and Availability

Before installation, verify:

• Correct app name
• Shopify App Store URL
• App developer or company name
• App category
• Current availability
• Current rating
• Current review count
• Last update information where available
• App website
• Documentation URL
• Support contact
• Pricing page
• Free plan or trial availability
• Supported Shopify plans
• Supported languages or regions where relevant

Important Rule

Do not assume that two similarly named apps are the same product.

Record the exact app and developer identity.

Step 3: Record Baseline App Information

Create the app research file and complete the basic information.

Required Fields

• App name
• App developer
• App category
• App Store URL
• Developer website
• Core use case
• Main target merchant
• Current rating
• Current review count
• Pricing model
• Free plan
• Free trial
• Installation requirements
• Required permissions
• Main integrations
• Testing level
• Research date
• Researcher name
• Technical reviewer
• Last verified date

Pricing, ratings, and review counts must include the date they were checked because they may change.

Step 4: Review the App’s Public Positioning

Before hands-on testing, study how the developer positions the app.

Review:

• App Store listing
• Main value proposition
• Feature claims
• Pricing claims
• Target merchants
• Screenshots
• Video demos
• FAQs
• Documentation
• Case studies
• Integration pages
• Support promises
• Changelog where available

Research Questions

• What problem does the app claim to solve?
• Which merchants does it appear to target?
• What outcomes does it promise?
• Which features are presented as differentiators?
• Are important limitations explained clearly?
• Does the pricing information appear transparent?
• Are the screenshots current and useful?

Output

A summary of the app’s public claims that will later be tested or verified.

Step 5: Review Permissions and Installation Requirements

Before installing, check:

• Requested store permissions
• Theme access
• Customer data access
• Order data access
• Product data access
• Marketing permissions
• Billing requirements
• External account requirements
• Required integrations
• Script or theme modifications
• Checkout or Shopify Plus requirements

Escalation Requirement

Escalate the app before installation when:

• Permissions appear excessive for its main function.
• Installation may affect the test store significantly.
• The app requires access to sensitive data.
• The app immediately requires paid billing.
• The app requires Shopify Plus.
• The app requires an external service contract.
• Testing may create real charges.

Do not approve paid plans without budget authorization.

Step 6: Install the App

Document the complete installation experience.

Evaluate:

• Number of installation steps
• Permission clarity
• Billing clarity
• Redirect process
• Account creation
• Email verification
• External platform setup
• Error messages
• Setup instructions
• Time required
• Initial dashboard experience

Record:

• Installation start time
• Installation completion time
• Any errors
• Required workarounds
• Screenshots
• Whether technical help was needed
• Whether the app added theme code or extensions

Installation Rating

Score the installation experience from 1 to 10 and explain the reason.

Step 7: Evaluate Onboarding

Assess how well the app guides a new merchant.

Review:

• Welcome screen
• Setup checklist
• Guided tutorial
• Sample data
• Video instructions
• Tooltips
• Help links
• Recommended configuration
• Progress indicators
• Default settings
• Time to first usable result

Questions

• Can a non-technical merchant understand the setup?
• Is the next step clear?
• Does the app explain important settings?
• Are default settings safe and practical?
• Can the merchant reach the first useful outcome quickly?
• Is specialist assistance likely to be required?

Output

Onboarding observations and a score from 1 to 10.

Step 8: Test the Core Use Case

The researcher must test the main task the app promises to perform.

Examples:

Review App

• Collect a product review
• Display reviews on a product page
• Moderate a review
• Import reviews if available
• Customize the review widget

Upsell App

• Create an offer
• Define targeting rules
• Display the offer
• Complete a test conversion
• Review offer analytics

Subscription App

• Create a subscription product
• Configure frequency
• Complete a test subscription
• Review customer-management options
• Test subscription changes where possible

Page Builder

• Create a page
• Use templates
• Customize sections
• Check mobile responsiveness
• Publish and preview the page

Dropshipping App

• Import a product
• Review supplier details
• Configure pricing
• Test order flow where possible
• Review fulfillment workflow

Testing Rule

The test should reflect a realistic merchant task, not simply clicking through the dashboard.

Record:

• Objective
• Steps completed
• Result
• Time required
• Difficulties
• Errors
• Quality of output
• Screenshots
• Feature limitations
• Required plan level

Step 9: Test Important Secondary Features

After the core use case, evaluate relevant secondary features.

Possible areas include:

• Automation
• Analytics
• Reporting
• Customization
• Segmentation
• Localization
• Import and export
• Permissions
• Multi-store support
• Customer portal
• Notification settings
• Template library
• Discounts
• Workflow rules
• Mobile experience
• AI-powered features
• Developer options
• API access
• Webhooks

Do not test irrelevant features simply to make the review longer.

Focus on features that affect the target merchant’s decision.

Step 10: Evaluate Dashboard and Usability

Review the app from a merchant’s perspective.

Evaluate:

• Navigation
• Menu structure
• Terminology
• Dashboard clarity
• Search and filtering
• Settings organization
• Error prevention
• Error recovery
• Loading speed
• Mobile usability
• Accessibility where observable
• Help availability
• Learning curve

Merchant Skill Levels

Assess suitability for:

• Beginner merchants
• Growing stores
• Advanced operators
• Agencies
• Developers
• Shopify Plus merchants

Output

A usability score and best-fit skill level.

Step 11: Evaluate Customization and Storefront Experience

For apps that affect the storefront, review:

• Visual quality
• Theme compatibility
• Mobile responsiveness
• Branding controls
• Layout options
• Font and style controls
• Widget placement
• User experience
• Accessibility concerns
• Customer-facing language
• Loading behavior
• Conflicts with existing theme elements

Evidence

Capture:

• Before installation
• After installation
• Desktop view
• Mobile view
• Main settings
• Final storefront output

Do not publish sensitive store information in screenshots.

Step 12: Check Performance and Technical Impact

Technical testing should match the app’s function and project resources.

Possible Checks

• New scripts loaded
• Network requests
• Page-weight changes
• Loading delays
• Theme code changes
• App embeds
• Theme app extensions
• Unused assets after uninstall
• JavaScript errors
• Console errors
• Mobile performance
• Compatibility with Online Store 2.0
• Checkout dependency
• Shopify Plus dependency
• Conflicts with other apps

Important Rule

Do not make a strong claim such as “this app slows down stores” based on one uncontrolled test.

Instead, document:

• Test environment
• Test page
• Testing method
• Before result
• After result
• Possible limitations

Technical concerns must be reviewed by a Shopify Developer or Expert before publication.

Step 13: Review Integrations

Evaluate integrations that matter to the target user.

Check:

• Native integrations
• Integration setup
• Additional costs
• Required accounts
• Data synchronization
• Supported workflows
• Integration documentation
• Limitations
• API or webhook availability
• Shopify Flow support
• Compatibility with common Shopify tools

Questions

• Are integrations truly native?
• Do they require a higher pricing plan?
• Is setup straightforward?
• Is data shared automatically?
• Are important integration limitations disclosed?

Do not describe an integration as tested unless it was actually tested.

Step 14: Verify Pricing

Pricing must be checked from an official and current source.

Record:

• Free plan
• Free trial
• Entry-level plan
• Mid-level plan
• Advanced plan
• Usage-based charges
• Order-based charges
• Revenue-based charges
• Feature restrictions
• Additional integration costs
• Setup fees
• Enterprise pricing
• Cancellation terms where available

Pricing Evaluation Questions

• Is pricing easy to understand?
• Does pricing increase with store growth?
• Which essential features require higher plans?
• Are there hidden or variable charges?
• What merchant size receives the best value?
• At what point may the app become expensive?

Important Rule

Always record the pricing verification date.

Avoid saying an app is “cheap” or “expensive” without explaining the merchant context and included value.

Step 15: Review Documentation and Help Resources

Evaluate the quality of:

• Help center
• Setup guides
• FAQs
• Video tutorials
• Troubleshooting content
• Developer documentation
• API documentation
• Changelog
• Product announcements
• In-app help

Score Based On:

• Clarity
• Completeness
• Searchability
• Freshness
• Examples
• Visual guidance
• Availability of technical documentation

Record important gaps that may affect merchants.

Step 16: Evaluate Customer Support

Support should only be tested when appropriate and necessary.

Possible Support Channels

• Live chat
• Email
• Ticket system
• Help center
• Community
• Phone
• Dedicated account support

Test Support With a Realistic Question

Ask a reasonable question related to:

• Setup
• Feature availability
• Pricing
• Integration
• Troubleshooting

Do not create unnecessary support work simply for testing.

Record:

• Channel used
• Date and time
• Response time
• Response quality
• Accuracy
• Helpfulness
• Whether the issue was resolved

Do not make universal claims about support quality based on one response. Combine the result with merchant-feedback patterns.

Step 17: Analyze Merchant Feedback

Merchant reviews should be analyzed for patterns, not copied individually.

Review Sources

• Shopify App Store reviews
• Public review platforms
• Relevant community discussions
• App case studies
• Support discussions where publicly available
• Social media feedback where credible

Review Sample

For each app, analyze a reasonable mix of:

• Recent positive reviews
• Recent critical reviews
• High-rating reviews
• Low-rating reviews
• Reviews mentioning setup
• Reviews mentioning support
• Reviews mentioning pricing
• Reviews mentioning reliability
• Reviews mentioning integrations
• Reviews mentioning business outcomes

Record Patterns

Identify:

• Most common strengths
• Most common complaints
• Repeated usability issues
• Repeated support experiences
• Pricing concerns
• Reliability concerns
• Common merchant use cases
• Store-size patterns
• Feature requests
• Review recency

Important Rules

• Do not treat every review as verified fact.
• Do not focus only on negative reviews.
• Do not copy long customer comments.
• Do not expose customer information unnecessarily.
• Separate Blinto’s observations from merchant-reported experiences.
• Note when feedback may relate to an older version of the app.

Output

A balanced merchant-feedback summary.

Step 18: Identify Best-Fit and Poor-Fit Merchants

The researcher must define who is most likely to benefit from the app.

Best-Fit Factors

• Store size
• Product type
• Sales volume
• Team size
• Technical ability
• Budget
• Required integrations
• Region
• Shopify plan
• Growth stage
• Operational complexity

Poor-Fit Factors

• Missing required features
• Budget mismatch
• Unsupported region
• Unsupported language
• Shopify Plus dependency
• Technical complexity
• Limited customization
• High-volume pricing concerns
• Limited integration support
• Need for a simpler solution

Output

Complete these statements:

Best for:
[Merchant type and use case]

May not be ideal for:
[Merchant type and limitation]

These statements must be supported by the research.

Step 19: Identify Strengths, Limitations, and Differentiators

Create three clear lists.

Strengths

What the app does especially well.

Limitations

What may prevent it from being suitable for certain merchants.

Differentiators

What meaningfully separates it from alternatives.

Avoid listing standard features as differentiators unless competitors genuinely lack them.

Step 20: Research Direct Alternatives

For every single-app review, identify relevant alternatives.

For every category review, identify the strongest apps in the category.

For every comparison article, confirm that the selected apps directly compete.

Alternative Research Fields

• App name
• Main difference
• Pricing difference
• Best-fit merchant
• Key advantage
• Key limitation
• Why a merchant may choose it instead

This research will support the future alternatives or comparison section.

Step 21: Complete the App Scoring Framework

Each app must be scored consistently.

Scoring Rules

• Every score must include a short justification.
• Scores must reflect the target merchant, not personal preference.
• Paid features that were not tested must be marked clearly.
• Merchant feedback may support the score but should not replace hands-on findings.
• Similar apps in the same category should be judged by the same criteria.
• The overall score should not be a simple mathematical average unless the team intentionally uses weighted scoring.

Recommended Score Meaning

11. Research Requirements by Content Format

Category or Bulk Review

For category reviews:

• Use the same evaluation criteria for every app.
• Create a comparison matrix.
• Identify the best app by use case.
• Avoid giving every app the same recommendation.
• Explain why each app was included.
• Remove apps that do not meet minimum evidence or quality standards.

Required Output

• Category criteria
• Shortlist
• Comparison matrix
• Individual app summaries
• Best-use-case labels
• Pricing comparison
• Final ranking or grouping

Single App Review

For single app reviews:

• Test the app more deeply.
• Document the full setup journey.
• Evaluate the main and secondary features.
• Define best-fit merchants.
• Identify limitations and alternatives.
• Collect enough evidence to support a standalone verdict.

Required Output

• Full research file
• Feature observations
• Screenshots
• Pricing details
• Merchant-feedback patterns
• App score
• Final research verdict

Comparison Article

For comparison articles:

• Test both apps using the same scenario where possible.
• Use the same store, theme, products, and evaluation criteria.
• Compare equivalent pricing levels.
• Identify clear winners by use case.
• Avoid declaring one universal winner when merchant needs differ.

Required Output

• Side-by-side comparison matrix
• Same-scenario test notes
• Pricing comparison
• Feature comparison
• Ease-of-use comparison
• Best-fit merchant for each app
• Evidence-based final recommendation

12. Evidence Collection Standards

Required Evidence

Where relevant, collect:

• App Store listing screenshot
• Pricing screenshot
• Installation screen
• Permission screen
• Onboarding screen
• Dashboard screen
• Key feature configuration
• Storefront result
• Mobile result
• Integration setup
• Analytics or reporting
• Error or limitation evidence
• Support interaction
• Uninstall result

Screenshot Rules

Screenshots must:

• Be clear and readable.
• Show only relevant information.
• Avoid private data.
• Avoid test passwords or API keys.
• Use consistent dimensions where possible.
• Include a descriptive filename.
• Record the capture date.
• Be stored in the correct project folder.
• Be approved before publication.

File-Naming Format

[App-Name][Feature-or-Screen][YYYY-MM-DD]

Example:

JudgeMe_Onboarding_2026-07-21.png

Evidence Notes

Every important screenshot should include:

• What it shows
• Why it matters
• Which claim it supports
• Whether it can be published

13. Research Documentation Template

Each app research file should include:

Section A: App Overview

• App name
• Developer
• Category
• Core use case
• Target merchant
• App Store information
• Pricing
• Integrations
• Testing level

Section B: Public Claims

• Main value proposition
• Key claimed features
• Claimed outcomes
• Differentiators

Section C: Hands-On Testing

• Installation
• Onboarding
• Core task
• Secondary features
• Usability
• Storefront experience
• Technical observations
• Integrations
• Support

Section D: Merchant Feedback

• Positive patterns
• Negative patterns
• Recurring concerns
• Recent feedback trends

Section E: Strategic Evaluation

• Best-fit merchants
• Poor-fit merchants
• Strengths
• Limitations
• Differentiators
• Alternatives
• App score
• Research verdict

Section F: Evidence

• Screenshots
• Videos
• Source links
• Testing dates
• Reviewer notes

14. Internal Knowledge Base Requirements

After testing, the app must be added to Blinto’s internal Shopify App Knowledge Base.

Required Knowledge-Base Fields

• App name
• Developer
• Category
• Main purpose
• Best-fit merchant
• Pricing model
• Key features
• Main strengths
• Main limitations
• Integrations
• Testing level
• Overall score
• Alternative apps
• Research owner
• Last tested date
• Last updated date
• Published content URLs
• Founder or partnership notes
• Refresh date

The knowledge base should allow the team to reuse research without repeating the entire process unnecessarily.

However, time-sensitive information such as pricing, ratings, and features must be verified again before publication or updates.

15. Technical Validation

A Shopify Developer or Expert must validate technical claims when the research includes:

• Store-performance impact
• Theme compatibility
• App code
• Script behavior
• API limitations
• Checkout restrictions
• Shopify Plus requirements
• Data synchronization
• Security concerns
• Uninstall behavior
• Integration architecture
• Webhooks
• Custom-development requirements

Technical Review Decisions

All technical review notes must be attached to the ClickUp task.

16. Research Quality Assurance Checklist

Before submitting the research, confirm:

• The correct app was evaluated.
• The testing level is documented.
• Public claims were separated from Blinto’s findings.
• Installation was documented.
• Core functionality was tested where possible.
• Important secondary features were reviewed.
• Pricing was verified from an official source.
• Pricing verification date was recorded.
• Merchant feedback was reviewed fairly.
• Recent and critical reviews were included.
• Best-fit and poor-fit merchants were identified.
• Strengths and limitations are evidence-based.
• Alternatives are directly relevant.
• Scores include explanations.
• Screenshots are organized.
• Sensitive information has been removed.
• Technical claims were validated.
• Research limitations are disclosed.
• The knowledge base was updated.
• The research can support the selected content format.

17. Approval Process

The Shopify Researcher submits the research for review.

Reviewer Responsibilities

The reviewer must confirm:

• The research answers the approved topic requirements.
• The app was tested at the documented level.
• Important claims are supported.
• Limitations are not hidden.
• Research is balanced.
• Pricing and app details are current.
• Merchant feedback is represented fairly.
• Scores are reasonable.
• Technical observations are approved.
• Evidence is stored correctly.
• The research is sufficient for content-brief creation.

Approval Decisions

18. ClickUp Requirements

Status Changes

At the beginning of testing:

Approved for Research → App Testing

After testing and documentation:

App Testing → Pending Research Review

After approval:

Pending Research Review → Research Completed

Required ClickUp Fields

• App name
• App category
• Content type
• Testing level
• Research owner
• Technical reviewer
• Testing start date
• Testing completion date
• Pricing verified date
• App score
• Research status
• Evidence folder
• Knowledge-base link
• Limitations
• Approval decision

Required Attachments

• Completed app research file
• Scoring sheet
• Screenshots
• Comparison matrix where relevant
• Merchant-feedback analysis
• Technical validation notes
• Pricing evidence
• Support notes where relevant
• Research-summary document

19. Recommended Timeline

The required time will vary by app complexity and content format.

Single App Review

Estimated total: 7–16 working hours

Comparison Article

Estimated total: 12–24 working hours, depending on the two apps.

Category Review

Testing all apps deeply may not be practical.

Recommended approach:

• Deep-test 2–4 leading apps.
• Partially test other selected apps where possible.
• Use transparent research-only evaluation for apps that cannot be installed.
• Apply the same minimum evidence standard to all included apps.

Estimated total: 20–40 working hours per category article, depending on the number and complexity of apps.

20. Common Mistakes to Avoid

Do not:

• Copy the app’s marketing claims as research findings.
• Claim first-hand testing when the app was not tested.
• Use only the App Store description.
• Test apps using real customer information.
• Approve paid plans without authorization.
• Judge support based on one delayed reply.
• Treat all merchant reviews as verified facts.
• Focus only on negative reviews.
• Ignore recent product changes.
• Compare apps using different criteria.
• Compare entry pricing for one app with enterprise pricing for another.
• Declare a universal winner without merchant context.
• Publish unsupported performance claims.
• Hide limitations to maintain a founder relationship.
• Score apps without written reasons.
• Store screenshots without filenames or context.
• Leave app code or test data after uninstalling.
• Move the task to content briefing before research approval.

21. Escalation Rules

Escalate to the Project Lead when:

• The app requires payment before meaningful testing.
• The app requests excessive permissions.
• The app creates unexpected charges.
• Testing affects store stability.
• The app appears insecure or suspicious.
• Installation adds code that cannot be removed easily.
• The app contains misleading pricing.
• Important claims cannot be verified.
• The app founder requests editorial control.
• A founder offers incentives for positive coverage.
• Merchant feedback raises serious trust concerns.
• Technical findings may create legal or reputational risk.
• The team cannot obtain enough evidence.
• The app changes significantly during research.
• The app is removed from the Shopify App Store.

The Project Lead may approve further testing, change the content format, replace the app, delay the content, or cancel the topic.

22. Test Store Cleanup

After testing, the researcher must:

• Export any needed test data.
• Capture final screenshots.
• Cancel test billing where necessary.
• Remove test automations.
• Remove test products or data where appropriate.
• Uninstall the app if no longer required.
• Check whether app code or assets remain.
• Restore the theme if needed.
• Record uninstall observations.
• Confirm that no unexpected charges remain.
• Update the test-store log.

Uninstall behavior may be relevant to the final review, especially if the app leaves code or configuration behind.

23. Definition of Done

SOP 2 is complete only when:

• The correct app has been researched.
• Testing level has been documented.
• Baseline information has been recorded.
• Public product claims have been reviewed.
• Installation and onboarding have been evaluated.
• The core merchant use case has been tested where possible.
• Important secondary features have been reviewed.
• Pricing has been verified.
• Integrations have been researched.
• Documentation and support have been evaluated.
• Merchant-feedback patterns have been analyzed.
• Best-fit and poor-fit merchants have been identified.
• Strengths, limitations, and differentiators are documented.
• Relevant alternatives have been identified.
• The scoring framework is complete.
• Screenshots and evidence are organized.
• Technical claims are validated.
• The internal knowledge base has been updated.
• Research QA has been completed.
• The reviewer has approved the research.
• The ClickUp status is Research Completed.

If any required item is missing, the task is not ready for SOP 3.

24. Handoff to SOP 3

After approval, the researcher prepares a concise handoff summary for the SEO Strategist and Content Lead.

Required Handoff Summary

• App or category
• Content format
• Testing level
• Core merchant problem
• Most important findings
• Best-fit merchant
• Poor-fit merchant
• Strongest features
• Important limitations
• Pricing observations
• Merchant-feedback patterns
• Main differentiators
• Relevant alternatives
• App score
• Technical notes
• Evidence folder
• Recommended content angle
• Claims that must not be made
• Information that requires disclosure

The task then moves to:

SOP 3: Shopify App Review Content Research and Brief Creation

SOP 3 will define:

• Keyword research
• Search-intent mapping
• Competitor-content analysis
• Content-angle selection
• Semantic topic coverage
• Article outline creation
• Internal-link planning
• CTA alignment
• Evidence placement
• Writer instructions
• Content-brief approval