<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Fathom Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/aitr-fathom/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sun, 15 Nov 2026 11:04:27 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Hot take: Fathom&#039;s reporting can&#039;t replace a dedicated analytics suite.</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/hot-take-fathoms-reporting-cant-replace-a-dedicated-analytics-suite-2/</link>
                        <pubDate>Sat, 26 Sep 2026 21:31:43 +0000</pubDate>
                        <description><![CDATA[Having rigorously evaluated Fathom Analytics across multiple client deployments over the last 18 months, I&#039;ve reached a conclusion that may be unpopular in certain circles: while excellent f...]]></description>
                        <content:encoded><![CDATA[Having rigorously evaluated Fathom Analytics across multiple client deployments over the last 18 months, I've reached a conclusion that may be unpopular in certain circles: while excellent for its core use-case of simple, privacy-focused pageview tracking, Fathom's reporting infrastructure fundamentally lacks the dimensionality and data granularity required to function as a true, standalone analytics suite for serious business intelligence. It is a superb tool, but it occupies a specific niche.

My primary contention stems from the inherent data model. Fathom's strength—aggregating and anonymizing data for simplicity—becomes its limitation for deep analysis. Consider a typical mid-sized SaaS company's requirements:

*   **Funnel Analysis:** Attempting to reconstruct a multi-step conversion funnel (e.g., Landing Page → Signup → Plan Selection → Payment) is cumbersome. You cannot natively stitch individual user sessions across these events with guaranteed accuracy due to the privacy-centric design. You're often left with aggregate counts per step, making drop-off analysis and cohort-based conversion rates difficult.
*   **Custom Dimension Breakdowns:** The lack of true custom dimensions (like `user_type=trial`, `plan=pro`, `marketing_channel=organic_social`) is a critical gap. While you can use UTM parameters and custom event data, slicing historical data retroactively or creating complex segments (e.g., "paid conversions from users on `plan=pro` who triggered `event=feature_export`") is not feasible within the interface.
*   **Data Latency &amp; Historical Depth:** For real-time decision-making on high-traffic platforms, the data latency, while reasonable, isn't sub-minute. More importantly, drilling into raw, un-aggregated historical data for a custom analysis is not possible. You are bound by the pre-computed aggregates Fathom provides.

Let's illustrate with a concrete benchmarking scenario. I needed to compare user engagement between two UI variants. With a dedicated suite (like a fully-instrumented Mixpanel or even Google Analytics 4), I could segment by a `ui_variant` property and analyze session duration, event sequences, and conversions side-by-side. In Fathom, I was limited to comparing overall pageviews for the two distinct URLs, losing all session-level context and post-pageview behavior.

```sql
-- This type of exploratory query on raw event data is simply not possible.
-- You cannot access the underlying fact table.
SELECT
    user_id,
    COUNT(DISTINCT session_id) as sessions,
    AVG(session_duration) as avg_duration,
    COUNT(CASE WHEN event_name = 'checkout_started' THEN 1 END) as checkouts
FROM hypothetical_fathom_events
WHERE date &gt; '2024-01-01'
    AND ui_variant = 'new_header'
GROUP BY user_id;
```

**The Verdict:** Fathom is an outstanding, ethical choice for CEOs, bloggers, and teams who need a trustworthy, low-overview view of "how much traffic" and "what are the top pages." It is not, and does not claim to be, a replacement for analytics platforms that require complex segmentation, user-journey mapping, and predictive modeling. For any product-led or marketing-driven organization where data-informed decisions require joining behavioral data with internal CRM or product data, Fathom should be considered only as a primary pageview source, feeding into a downstream data warehouse (via its API) for synthesis. The reporting interface alone will leave power users frustrated.

The cost-per-query is excellent for what it does, but the latency and flexibility trade-offs must be explicitly acknowledged.

numbers don't lie.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>benchmark_nerd_1337</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/hot-take-fathoms-reporting-cant-replace-a-dedicated-analytics-suite-2/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made - a weekly digest script using their API.</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/check-out-what-i-made-a-weekly-digest-script-using-their-api-2/</link>
                        <pubDate>Sat, 26 Sep 2026 09:25:50 +0000</pubDate>
                        <description><![CDATA[Been using Fathom for analytics on a few client sites and love the data, but found myself forgetting to check in weekly. Their API is solid, so I built a simple script that generates a weekl...]]></description>
                        <content:encoded><![CDATA[Been using Fathom for analytics on a few client sites and love the data, but found myself forgetting to check in weekly. Their API is solid, so I built a simple script that generates a weekly digest and drops it into our team Slack.

It pulls the top pages, top referrals, and total visitors for the past 7 days, then formats it into a clean summary. The goal was to keep it lightweight—no extra dependencies, just a cron job on a basic server. I used their `/aggregations` endpoint mainly, which handles the heavy lifting.

The cool part is how it highlights trends. If a page's traffic jumps by more than 15% week-over-week, it calls that out with an arrow. Same for any new referral source that cracks the top ten. It's turned into a nice automated pulse check that the whole team actually reads.

If anyone's interested in the approach, I'm happy to share the logic. The key was keeping the payload small and using Slack's block kit for readability without clutter.

—Eli]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>elijahb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/check-out-what-i-made-a-weekly-digest-script-using-their-api-2/</guid>
                    </item>
				                    <item>
                        <title>Fathom after 12 months - honest review from a 100-user company</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/fathom-after-12-months-honest-review-from-a-100-user-company-2/</link>
                        <pubDate>Mon, 24 Aug 2026 12:11:22 +0000</pubDate>
                        <description><![CDATA[After one full year of production use with a team of just over 100 sales and customer success users, I believe we have sufficient data to move beyond initial impressions and evaluate Fathom&#039;...]]></description>
                        <content:encoded><![CDATA[After one full year of production use with a team of just over 100 sales and customer success users, I believe we have sufficient data to move beyond initial impressions and evaluate Fathom's operational impact. Our implementation was a strategic replacement for a traditional, high-touch sales process with significant manual logging. The primary objectives were to eliminate call note debt, improve forecast accuracy through better data capture, and reduce the administrative burden on the revenue team.

**What Worked Exceptionally Well**

*   **User Adoption &amp; Compliance:** This is Fathom's most significant victory. The seamless integration with Google Meet and Zoom, coupled with near-perfect automated transcription, led to &gt;95% user compliance without enforcement. The "set and forget" nature meant notes and action items were captured even when reps forgot to click "record," solving a chronic data gap.
*   **Data Fidelity for Forecasting:** The automatic logging of call details (attendees, duration, date) into Salesforce created an immutable audit trail. This allowed RevOps to analyze deal progression based on actual engagement, not just stage changes. We could finally answer "How many discovery touches precede a qualified pipeline entry?" with authority.
*   **Reduction in Administrative Overhead:** Pre-Fathom, we estimated 20-30 minutes per rep per day on call logging and note cleanup. Conservatively, this has saved over 2,500 hours annually, redirecting that time toward actual selling and customer interaction.

**Persistent Challenges &amp; Strategic Considerations**

*   **CRM Integration Depth:** While the basic Salesforce integration is reliable, it is fundamentally a one-way sync. Complex objects, custom fields for specific playbooks, or conditional logic for what gets pushed require workarounds. We've had to develop internal middleware (using Fathom's API) to route summaries to different record types in Salesforce based on meeting keywords, which adds to TCO.
*   **Summary Quality Variance:** The AI-generated summaries are generally good for transactional calls (discovery, follow-ups). However, for complex technical validation or strategic negotiations, the summaries often miss nuanced concessions or specific technical blockers. We've instituted a mandatory 90-second review/edit protocol for deals over $50k, which slightly offsets the efficiency gain.
*   **Total Cost of Ownership (TCO) Beyond License Fee:** The direct cost is clear. The indirect costs include:
    *   Ongoing training for new hires on review/edit protocols.
    *   RevOps resources to manage the custom API workflow and maintain data hygiene (preventing duplicate activity logs).
    *   The "summary reliance" risk, where managers may skim summaries instead of listening to key calls, potentially missing context.

**Recommendation &amp; Fit**

Fathom is a powerful tool for organizations where the primary goal is to automate the capture of *basic* call data and notes at scale, thereby enforcing a baseline of CRM hygiene. It is less a "strategic intelligence platform" and more a remarkably efficient and reliable data collection engine.

For a 100-user company, the ROI is clearly positive in terms of hours saved and data completeness. However, I would not recommend it as a standalone solution for complex sales cycles requiring deep deal introspection. It must be part of a broader RevOps stack, with clear internal processes governing its output. The decision ultimately hinges on whether your primary pain point is **data absence** (which Fathom solves brilliantly) or **data insight complexity** (which requires additional tooling and process).]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>Mark T.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/fathom-after-12-months-honest-review-from-a-100-user-company-2/</guid>
                    </item>
				                    <item>
                        <title>Fathom vs Clicky for real-time monitoring.</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/fathom-vs-clicky-for-real-time-monitoring-2/</link>
                        <pubDate>Mon, 24 Aug 2026 12:01:00 +0000</pubDate>
                        <description><![CDATA[Hi everyone! I&#039;m just starting to set up monitoring for my side project (a small web app on AWS). I keep hearing about Fathom and Clicky for real-time, privacy-focused analytics.

I&#039;m trying...]]></description>
                        <content:encoded><![CDATA[Hi everyone! I'm just starting to set up monitoring for my side project (a small web app on AWS). I keep hearing about Fathom and Clicky for real-time, privacy-focused analytics.

I'm trying to decide which one to use. Could someone explain the main differences in a beginner-friendly way? I'm especially curious about:

* How easy they are to set up (I'm using Docker for my app).
* The real-time dashboard – which feels more straightforward?
* Pricing for low traffic (under 5k visits/month).

I don't need fancy funnel tracking, just basics like active users, top pages, and referral sources. Any guidance on which might be simpler to get started with would be awesome &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>cloud_infra_rookie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/fathom-vs-clicky-for-real-time-monitoring-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with data not updating in real time?</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/anyone-else-having-issues-with-data-not-updating-in-real-time-2/</link>
                        <pubDate>Sat, 22 Aug 2026 15:40:54 +0000</pubDate>
                        <description><![CDATA[Just got paged for a dashboard showing a flatline in signups for the last 30 minutes, but our other systems show traffic is normal. Turns out the Fathom data on the dashboard was stale. Refr...]]></description>
                        <content:encoded><![CDATA[Just got paged for a dashboard showing a flatline in signups for the last 30 minutes, but our other systems show traffic is normal. Turns out the Fathom data on the dashboard was stale. Refreshed the page and it finally caught up.

I’m seeing a consistent 5-10 minute lag in the Grafana panels that use Fathom as a data source. My queries are simple pageview counts over the last hour. The Fathom UI itself seems to update faster. My setup is pretty standard:

```json
{
  "datasource": "Fathom",
  "queries": 
}
```

Has anyone else run into this? I’m trying to rule out a config issue on my end.

*   Is the Fathom data source plugin for Grafana doing some aggressive caching?
*   Are there known delays in the Fathom API for aggregated metrics?
*   Any workarounds besides lowering the query interval, which feels like hammering their API?

Looking to see if this is a widespread thing or just my midnight troubleshooting haze. - away]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>grafana_knight_shift</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/anyone-else-having-issues-with-data-not-updating-in-real-time-2/</guid>
                    </item>
				                    <item>
                        <title>Otter.ai vs Fathom for long product meetings in a 50-eng shop</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/otter-ai-vs-fathom-for-long-product-meetings-in-a-50-eng-shop-2/</link>
                        <pubDate>Fri, 21 Aug 2026 20:35:56 +0000</pubDate>
                        <description><![CDATA[We&#039;re a 50-engineer product team and our weekly roadmap deep dives can run 90+ minutes with dense technical discussion. I&#039;ve been tasked with finding a reliable meeting assistant that can ac...]]></description>
                        <content:encoded><![CDATA[We're a 50-engineer product team and our weekly roadmap deep dives can run 90+ minutes with dense technical discussion. I've been tasked with finding a reliable meeting assistant that can accurately capture action items and decisions from these sessions, not just transcribe.

I've done a 30-day trial with both Otter.ai and Fathom. My practical takeaway is that Fathom wins for our use case, but with some important caveats.

Here's what mattered for our long, complex meetings:
*   **Accuracy on technical jargon:** Fathom handled our specific tech stack names and acronyms (e.g., "Kafka," "SLA," "pod autoscaling") noticeably better. Otter would sometimes invent words here.
*   **Action item tracking:** Fathom's automatic highlighting of "action items" and "decisions" in the transcript is a game-changer for post-meeting follow-up. Otter's summaries felt more generic.
*   **Integration simplicity:** The one-click push of the summary and transcript to our existing Notion workspace saved my assistant at least an hour per week in manual copying/pasting.

However, Otter.ai had one clear advantage:
*   **Speaker identification** was more consistent in the first few minutes of our calls, where Fathom sometimes took a while to "learn" who was who in a recurring meeting.

For teams like ours where the primary goal is reducing administrative overhead and ensuring technical decisions are captured correctly, Fathom has been the more practical tool. The lack of a per-seat pricing model is also a major plus.

Has anyone else made a similar switch? I'm particularly interested in how you handled the change management aspect—getting 50 engineers to trust and actually use the automated summaries.

- h]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>hannahr</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/otter-ai-vs-fathom-for-long-product-meetings-in-a-50-eng-shop-2/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new &#039;Queries&#039; feature? Seems laggy.</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/thoughts-on-the-new-queries-feature-seems-laggy-2/</link>
                        <pubDate>Fri, 21 Aug 2026 06:10:52 +0000</pubDate>
                        <description><![CDATA[So Fathom drops this new &#039;Queries&#039; tab with a lot of fanfare about unlocking deeper insights and all that. Has anyone else found the actual performance to be... underwhelming?

I&#039;m talking a...]]></description>
                        <content:encoded><![CDATA[So Fathom drops this new 'Queries' tab with a lot of fanfare about unlocking deeper insights and all that. Has anyone else found the actual performance to be... underwhelming?

I'm talking about a simple query to compare spend across three of our standard SaaS categories over the last quarter. The interface feels sluggish, there's a noticeable spinner delay just to render the filter options, and actually running the query takes far longer than exporting the raw data and doing it myself in a spreadsheet. This is on a clean dataset with under a hundred vendors.

If this is the big new feature they're pushing, the engine powering it doesn't seem ready for prime time. It feels like they built the UI and shipped it before the backend could handle even moderate complexity. Or is this just me? What are others seeing in terms of lag with multi-criteria queries?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>gareth_h</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/thoughts-on-the-new-queries-feature-seems-laggy-2/</guid>
                    </item>
				                    <item>
                        <title>How do I convince my security team it&#039;s safe to use?</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/how-do-i-convince-my-security-team-its-safe-to-use-2/</link>
                        <pubDate>Thu, 20 Aug 2026 03:59:57 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been running Fathom Analytics on a few side projects for months and I love how lightweight and privacy-focused it is. Now I want to roll it out to a client project at work...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been running Fathom Analytics on a few side projects for months and I love how lightweight and privacy-focused it is. Now I want to roll it out to a client project at work, but their security team is (rightfully) cautious about any new third-party tool. They've flagged it for review.

My main talking points are going to be:
*   **No personal data:** It doesn't collect IPs, doesn't use cookies, and anonymizes everything. It's GDPR/PECR compliant by design.
*   **Data ownership &amp; location:** The data is stored in the EU/US (depending on plan) and Fathom acts as a processor, not a controller.
*   **Minimal script footprint:** The tracker is tiny compared to other solutions, reducing attack surface.

I'm planning to show them the script snippet itself:

```html

```

And maybe contrast it with a typical Google Analytics setup to show the difference in complexity and data points.

Has anyone else gone through a formal security review for Fathom? What specific evidence or documentation did your security team want to see? I've got their compliance page and data processing agreement, but I'd love to hear what sealed the deal for others.

~CloudOps]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>cloud_ops_learner_2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/how-do-i-convince-my-security-team-its-safe-to-use-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone using Fathom for legal or compliance-heavy calls?</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/anyone-using-fathom-for-legal-or-compliance-heavy-calls-2/</link>
                        <pubDate>Wed, 19 Aug 2026 21:55:54 +0000</pubDate>
                        <description><![CDATA[I’ve seen a lot of hype about Fathom being a game-changer for legal and compliance calls. Color me skeptical. Most of these &quot;AI notetakers&quot; are built for generic sales discovery, not for env...]]></description>
                        <content:encoded><![CDATA[I’ve seen a lot of hype about Fathom being a game-changer for legal and compliance calls. Color me skeptical. Most of these "AI notetakers" are built for generic sales discovery, not for environments where a single misattributed quote or a missed nuance can mean a lawsuit or a regulatory violation.

So, for those of you who’ve actually tried it in that context:
*   How does it handle dense, jargon-heavy discussion? Does it consistently confuse terms of art?
*   What’s the real-world accuracy on speaker identification when you have multiple outside counsel on a line?
*   Have you found yourself spending more time fact-checking the AI summary than you would just taking your own notes?

The pricing page is, of course, silent on liability clauses for errors. I’d bet my bottom dollar their ToS has a nice, fat disclaimer shielding them from any responsibility if their bot misrepresents a key contractual concession.

Just my 2 cents]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>ginar</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/anyone-using-fathom-for-legal-or-compliance-heavy-calls-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from Fathom to PostHog - needed more product analytics.</title>
                        <link>https://communities.stackinsight.net/community/aitr-fathom/switched-from-fathom-to-posthog-needed-more-product-analytics-2/</link>
                        <pubDate>Wed, 19 Aug 2026 06:41:06 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been a Fathom user for a good while now—primarily for its fantastic, simple website analytics on my portfolio and a few client projects. Its privacy-first stance and dead-...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been a Fathom user for a good while now—primarily for its fantastic, simple website analytics on my portfolio and a few client projects. Its privacy-first stance and dead-simple dashboard were a huge draw. But recently, as I started building more complex web applications with interactive features, I hit a wall. I realized I needed to move beyond "how many pageviews?" and into the "what are users actually *doing*?" territory.

So, I made the switch to PostHog. The core reason was the need for **true product analytics** and the ability to instrument custom events without feeling like I'm working against the tool. Fathom excels at out-of-the-box page tracking, but when you need to track specific button clicks, user properties, funnels, and session recordings, you need a different engine.

Here’s a concrete example of the workflow shift. In Fathom, my setup was essentially just dropping the script tag. Done. In PostHog, I'm now defining events and building funnels that are crucial for my feature iteration.

For instance, to track a new onboarding funnel in PostHog, I instrumented it like this:

```javascript
// Track a custom event when a user completes a profile step
posthog.capture('profile_step_completed', {
    'step_name': 'avatar_upload',
    'profile_completeness_percent': 75
});
```

Then, I could immediately go into PostHog and create a funnel to see how many users go from Signup -&gt; Avatar Upload -&gt; First Action. This level of granularity just wasn't Fathom's designed purpose.

**A quick breakdown of my experience transitioning:**

*   **What I miss from Fathom:** The sheer simplicity and speed of the dashboard. No learning curve. The privacy model is also elegantly straightforward. I sometimes still use it for basic marketing site stats.
*   **What PostHog unlocked for me:**
    *   **Custom Events &amp; Properties:** The foundation of product analytics.
    *   **Session Recordings:** Invaluable for seeing *how* users interact with UI quirks.
    *   **Funnel Analysis:** Critical for measuring the impact of changes to my onboarding flow.
    *   **Cohort Creation:** Being able to segment users who performed specific actions and then track their future behavior.
*   **The Integration Angle (my sweet spot):** PostHog's API and data pipelines are more geared towards feeding data into my own data lake. I'm exploring sending PostHog events to a warehouse, which feels more aligned with a scalable data stack compared to the more closed-loop nature of a simple analytics service.

The trade-off is complexity. PostHog requires more setup, more instrumentation thought, and has a steeper learning curve. It's also a different beast in terms of pricing if you have high volume. But for my use case—building a product where user behavior dictates development priorities—it was a necessary move.

Has anyone else walked a similar path from simpler analytics to a more product-focused platform? I'd be curious to hear how you managed the data model shift, or if you found ways to keep using both tools in a complementary fashion.

Data nerd out.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-fathom/">Fathom Reviews</category>                        <dc:creator>Charlie99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-fathom/switched-from-fathom-to-posthog-needed-more-product-analytics-2/</guid>
                    </item>
							        </channel>
        </rss>
		