Shariff Laravel Package

Product Decisions This Supports

• Privacy-Compliant Social Sharing Analytics: Enables tracking of social media shares (Facebook, Reddit, Pinterest, etc.) without relying on third-party scripts (e.g., Facebook Pixel, Twitter Cards) that may violate GDPR/CCPA by default. Aligns with privacy-first product strategies (e.g., "No Trackers" initiatives).
• Build vs. Buy: Avoids reinventing a privacy-preserving social share counter. Reduces dev effort compared to custom solutions while maintaining compliance.
• Roadmap Priorities:
  • Phase 1: Integrate into existing Laravel apps (e.g., blog/news platforms) to replace legacy share counters (e.g., AddThis, ShareThis).
  • Phase 2: Extend to mobile apps (via API) or headless CMS (e.g., Strapi) for unified analytics.
  • Phase 3: Add real-time notifications (e.g., Slack alerts for viral content) by hooking into the backend’s JSON responses.
• Use Cases:
  • Publisher Sites: Track engagement without third-party trackers (e.g., news outlets, SaaS blogs).
  • E-Commerce: Monitor product page shares (e.g., "Pinterest saves" as a KPI).
  • Internal Tools: Embed in admin dashboards to surface trending content.

When to Consider This Package

• Adopt If:

  • Your product prioritizes privacy compliance (GDPR/CCPA) and avoids third-party scripts that trigger tracking consent dialogs.
  • You need lightweight, self-hosted share counters (no reliance on external APIs like Twitter Cards).
  • Your stack is Laravel/PHP (or can integrate a PHP microservice).
  • You require customizable caching (e.g., Redis for high-traffic sites) or domain whitelisting for security.
  • You’re replacing AddThis/ShareThis or want to avoid Facebook’s deprecated FQL API.

• Look Elsewhere If:

  • You need real-time share updates (this package caches counts; consider Facebook’s Graph API directly for live data).
  • Your primary platform is non-PHP (e.g., Node.js, Python). Use alternatives like ShareThis or AddThis API.
  • You require multi-language support (this package is PHP-only; frontend Shariff is JS-based).
  • Your use case demands advanced analytics (e.g., demographic data), which Shariff doesn’t provide.

How to Pitch It (Stakeholders)

For Executives:

"Shariff lets us track how users share our content on social media—without the privacy risks or performance drag of third-party scripts. It’s self-hosted, GDPR-compliant, and integrates seamlessly with our Laravel stack. For example, Heise.de (a German media giant) uses it to avoid Facebook’s tracking pitfalls while still measuring engagement. This aligns with our [Privacy by Design](insert link) initiative and reduces dependency on external vendors. ROI: Lower legal risk, faster page loads, and actionable data for content teams."

Ask:

• "Should we prioritize this for [Product X]’s next release to replace [current solution]?"
• "Would you like a demo of how this fits into our analytics dashboard?"

For Engineering:

*"Shariff is a batteries-included PHP package that handles the heavy lifting of privacy-compliant social share counting. Here’s how we’d leverage it:

1. Integration:

   • Deploy the backend as a Laravel microservice (e.g., /api/shariff) or drop it into an existing project.
   • Use the OO interface (Backend class) to fetch counts programmatically:

     $shariff = new \Heise\Shariff\Backend($config);
     $counts = $shariff->get('https://example.com/article');
     

   • Cache responses aggressively (default: 60s TTL) to reduce API calls.

2. Customization:

   • Cache Backend: Swap the default LaminasCache for Redis (recommended for scale) or APCu for low-latency environments.
   • Services: Enable only what you need (e.g., ['Facebook', 'Pinterest']) to minimize API calls.
   • Facebook Auth: Use the app_id/secret config to fetch real-time counts via Graph API (requires a Facebook Developer account).

3. Frontend:

   • Pair with the Shariff frontend (JavaScript) to render share buttons without external trackers.
   • Example: Replace <div class="share-this"></div> with Shariff’s privacy-friendly buttons.

4. Scaling:

   • Load Testing: Monitor Guzzle timeouts (default: 4.2s) and adjust client options (e.g., timeout, retries).
   • Monitoring: Log service failures (e.g., Facebook API downtime) via the built-in logger.

Trade-offs:

• No real-time data: Counts are cached; for live updates, poll the backend every 5–10 minutes.
• Maintenance: Keep dependencies updated (e.g., Facebook Graph API v25.0 in v11.0.0).

Next Steps:

• Spin up a test instance to validate counts for our top 10 URLs.
• Benchmark performance vs. our current solution.
• Propose a feature flag to roll this out to 10% of traffic first."*

Ask:

• "Should we containerize this as a Docker service for consistency across environments?"
• "Do we need to extend the CacheInterface for our specific caching layer?"