Skip to main content

Hi Community folks!

We’ve been exploring how we can use login gating certain parts of our Community to encourage people to Register their accounts (which is very simple, they just login through SSO of our platform), and subsequently login more frequently so we have better insights and analytics. We also want to protect certain information from public visibility or make it exclusive to customers to see.

Would be very interested in how others have tackled this?

  • What areas did you find more effective to put as a login gate?
  • What are the things to be cautious of? We don’t want to add unnecessary friction to customers’ experience of finding info they need
  • Is there a way to make the questions searchable publicly, but then to open/ read the full topic you need to sign-in first?

Ultimately it’s about getting  people from not logged in → passive lurkers → engaged likers → conversation participants

Thanks in advance! Happy to share more on what we’re trying to achieve.

As Karl highlights above, we’re really interested to hear about this topic!


Hey Karl, sorry for the late response here - we must have missed this one!  Would also love to hear what others in the community think, but here are a few quick thoughts:

  • As you might know, we generally recommend going as open as possible, simply because any kind of gate acts as a barrier to engagement.  That said, there are many good reasons to gate some parts of a community (as we also do ourselves) - and some of our customers have good reasons for keeping their communities entirely private, even if that does make it harder to grow the community over time.
  • The big benefits of a hybrid approach where at least some of the community is visible to visitors who aren’t logged in are in improving findability of the community and removing one major barrier to entry.  It also greatly reduces the ‘time to value’, as @DannyPancratzexplained to us in this webinar we did last year, especially if you have your community set up as a central hub - visitors can benefit from that well before registering or contributing.
  • It’s not possible to make topics searchable but then force a login when wanting to view the whole topic.  I think the best practice, rather, is to identify some areas that can be viewed publicly and that are going to be valuable enough to demonstrate to a first-time visitor that your community is a useful place to be (and hopefully get you a bit of SEO value as well).  I would personally always challenge myself to be as open as possible and only lock down areas that really need to be locked down.
  • The other major tip I would give (probably also an obvious one) is to really emphasise CTAs (call-to-actions) for registering and logging into the community.  The big downside with having areas walled-off is that the first-time visitor may not know that (much) more great content is available, so you’ll want to include prominent pointers to register and log in.  That can be via widgets in the homepage and sidebar (with a bit of nifty script those can be shown only to visitors who aren’t logged-in) or you could even incorporate a friendly pop-up (also would need a bit of script).  Emphasising login in these kinds of ways is essential if you have quite a lot of the community walled-off.

Just a few thoughts from me.  🙂 Happy to chat more here if you have follow-up questions.


As Kenneth mentioned, there’s not really a way to make the questions searchable, but the answers gated. 

I don’t know that I’d recommend this, but…

If you really really want something like this, federated search could be an imperfect solution. 

  • Federated search results are visible while logged-out (you feed them in via this API call)
  • If you recreated each question you want to index, you could add a second, incomplete version of them to search
  • When they click the link, the gated question post would force them to log in. 

Federated search works off unique URLs, so you’d probably need to add a UTM tag on the end of the URL to make it different from the URLs the search natively indexes from the question. 

If it were me doing this, I would... 

  1. Automate adding details to a google sheet based on a moderator tag
  2. Do an initial audit of (only answered) questions I want to index in search
  3. Index the initial list from that google sheet via the API
  4. Automate adding that moderator tag whenever an answer is marked
  5. Automate indexing the new answers added to that sheet (trigger: new spreadsheet row)

All of those automations are possible with Zapier. 

Here’s why it’s not ideal: Those federated search results will also show when you’re logged in. So you’re created two versions of the same post. Federated results show below content that is natively on the community, but it’s still not the cleanest UX. And if Gainsight improves the search UX, you could be in trouble. 

 


We accidentally managed to do exactly this a year ago, when we did a complete refresh of the community look and feel, and also cleaned up in some old content across our three communities.

Effectively what happened was that we moved a lot of well-visited (high page view) but also outdated content to an archive area, where you as a user would have to sign up / log in to read it. However.. Google, and other search engines, don’t forget that easily, which means that the -now gated- content drove an absolutely staggeringly insane amount of new member sign ups.

So, task failed successfully.

 


Reply