Meteor template subscriptions and performance - mongodb

Question

I'm looking for advice on my approach here- I want to be sure I'm doing things in the "meteor way" and keeping the code fast.
Current situation:
We have a collection for Questions. Each question has a nested collection of Answers. Through a REST API, a device relays the answers that were selected by users.
Based on the answers that were selected, we show a chart for each question- simple number breakdowns and percentage bars. To improve performance, we've been tracking the number of responses each Answer has received on the Answer itself.
The publication looks (basically) like this:
Meteor.publish('questionsBySiteID', function(site_id){
return Questions.find({site_id: site_id});
});
And the route like this:
Router.route('/sites/:_id/questions', {
name: 'questionsList',
waitOn: function(){
return [
Meteor.subscribe('questionsBySiteID', this.params._id),
];
},
data: function(){
return {
publishedQuestions: Questions.find(
{ site_id : this.params._id, active: true, deleted: {$ne: true} },
{ sort : { order: 1} }
),
archivedQuestions : Questions.find(
{ site_id : this.params._id, active: false, deleted: {$ne: true} },
{ sort : { updated_at: -1 } }
),
deletedQuestions : Questions.find(
{ site_id : this.params._id, deleted: true },
{ sort : { updated_at: -1 } }
)
};
}
});
Change required:
Now we want responses to be date-filterable. This means the denormalized response counts we've tracked on Answers aren't very useful. We've been tracking another collection (Responses) with more a "raw" version of the data. A Response object tracks the module (questions in this case), question_id, answer_id, timestamp, id for the customer the question belongs to, etc.
Question:
Is this something that template subscriptions help with? Perhaps we need a publication that accepts a question_id and optional start/end dates for the filter. The stats template for each question would be subscribed to applicable Responses data in Template.question.create(). Based on the question_id, the publication would need to find Responses for related answers within the date filter. And maybe we use the publish-counts package to count the number of times each answer was selected and publish those counts.
The Responses collection will be quite large, so I'm trying to be careful about what I publish here. I don't want to waitOn all Responses to be published.